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《 Ceph 运 维 手册 》 汇 总 了 Ceph 在 使 用 中 常见 的 运 维和 操作 问题 ， 主 要 用 于 指导 
运 维 人 员 的 相关 工作 。 ee 
过 本 手册 进一步 深入 Ceph 的 使 用 和 运 维 。 


本 书 的 内 容 大 部 分 来 自 Ceph 官方 文档 ， 另 一 部 分 来 自 技 术 博 客 ， 还 有 一 部 分 来 自 
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环境 
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第 一 部 分 : 常用 操作 


本 部 分 介绍 了 Ceph 集群 的 常用 操作 ， 包 括 进程 的 起 停 、 集 群 的 监控 、 用 户 管理 、 


MON/OSD 的 增加 和 删除 、 存 储 池 的 操作 、 修 改 集群 的 配置 ， 以 及 Crushmap 的 管 
理 、 修 改 Monitor 的 IP 等 操作 。 


1. 操作 集群 


1.1 用 UPSTART 控制 CEPH 


用 ceph-deploy 把 Ceph Cuttlefish 及 更 高 版 部 署 到 Ubuntu 14.04 上 ， 你 可 以 用 基 
于 事件 的 Upstart 来 启动 、 关 闭 Ceph 节点 上 的 守护 进程 。Upstart 不 要 求 你 在 配 
置 文件 里 定义 守护 进程 例 程 。 


1.1.1 列 出 节点 上 所 有 的 Ceph 作业 和 实例 
sudo initctl list | grep ceph 

1.1.2 局 动 所 有 守护 进程 

要 启动 某 一 Ceph 节点 上 的 所 有 守护 进程 ， 用 下 列 命令 : 
sudo start ceph-all 

1.1.3 停止 所 有 守护 进程 

要 停止 某 一 Ceph 节点 上 的 所 有 守护 进程 ， 用 下 列 命令 : 
sudo stop ceph-all 


1.1.4 按 类 型 启动 所 有 守护 进程 


要 启动 某 一 Ceph 节点 上 的 某 一 类 守护 进程 ， 用 下 列 命令 : 


sudo start ceph-osd-all 
sudo start ceph-mon-all 
sudo start ceph-mds-all 


1.1.5 按 类 型 停止 所 有 守护 进程 
要 停止 某 一 Ceph 节点 上 的 某 一 类 守护 进程 ， 用 下 列 命令 : 
sudo stop ceph-osd-all 


sudo stop ceph-mon-all 
sudo stop ceph-mds-all 


1.1.6 启动 单个 进程 
要 启动 某 节点 上 一 个 特定 的 守护 进程 例 程 ， 用 下 列 命令 之 一 : 
sudo start ceph-osd id={id} 


sudo start ceph-mon id={hostname} 
sudo start ceph-mds id={hostname} 


例如 : 


sudo start ceph-osd id=1 
sudo start ceph-mon id=ceph-server 
sudo start ceph-mds id=ceph-server 


1.1.7 停止 单个 进程 
要 停止 某 节点 上 一 个 特定 的 守护 进程 例 程 ， 用 下 列 命令 之 一 : 
sudo stop ceph-osd id={id} 


sudo stop ceph-mon id={hostname} 
sudo stop ceph-mds id={hostname} 


例如 : 
sudo stop ceph-osd id-1 


sudo stop ceph-mon id=ceph-server 
sudo stop ceph-mds id=ceph-server 


1.2 用 SYSTEMD 控制 CEPH 


对 于 所 有 支持 systemd 的 Linux 发 行 版 (CentOS 7, Fedora, Debian Jessie 8.x, 
SUSE) ， 使 用 原生 的 systemd 文件 来 代替 传统 的 sysvinit 脚本 。 不 过 需要 
注意 ， 这 和 Ceph 的 版 本 也 有 关系 。 如 果 CentOS 7 + Jewel， 使 用 的 就 是 


systemd ^? 


1.2.1 列 出 节点 上 所 有 的 Ceph systemd units 
sudo systemctl status ceph\*.service ceph\*.target 
1.2.2 局 动 所 有 守护 进程 
要 启动 某 一 Ceph 节点 上 的 所 有 守护 进程 ， 用 下 列 命令 : 
sudo systemctl start ceph.target 
1.2.3 停止 所 有 守护 进程 
要 停止 某 一 Ceph 节点 上 的 所 有 守护 进程 ， 用 下 列 命令 : 
sudo systemctl stop ceph\*.service ceph\*.target 


1.2.4 按 类 型 启动 所 有 守护 进程 


要 启动 某 一 Ceph 节点 上 的 某 一 类 守护 进程 ， 用 下 列 命令 : 


sudo systemctl start ceph-osd.target 
sudo systemctl start ceph-mon.target 
sudo systemctl start ceph-mds.target 


1.2.5 按 类 型 停止 所 有 守护 进程 
要 停止 某 一 Ceph 节点 上 的 某 一 类 守护 进程 ， 用 下 列 命令 


sudo systemctl stop ceph-mon\*.service ceph-mon.target 
sudo systemctl stop ceph-osd\*.service ceph-osd.target 
sudo systemctl stop ceph-mds\*.service ceph-mds.target 


1.2.6 司 动 单 个 进 


要 启动 某 节 点 上 一 个 特定 的 守护 进程 例 程 ， 用 下 列 命令 之 一 : 


sudo systemctl start ceph-osd@{id} 
sudo systemctl start ceph-mon@{hostname} 
sudo systemctl start ceph-mds@{hostname} 


1.2.7 停止 单个 进程 


要 停止 某 节点 上 一 个 特定 的 守护 进程 例 程 ， 用 下 列 命令 之 一 : 


sudo systemctl stop ceph-osd@{id} 
sudo systemctl stop ceph-mon@{hostname} 
sudo systemctl stop ceph-mds@{hostname} 


一 一 


1.3 把 CEPH Z JR 4-35 4 


在 某 些 环境 下 ， 还 可 以 把 Ceph 当做 服务 来 运行 ， 比 如 CentOS 7 + Hammer » 


1.3.1 启动 所 有 守 


要 启动 本 节点 上 的 所 有 Ceph 守护 进程 ， 用 下 列 命令 : 
sudo service ceph [start|restart] 

1.3.2 停止 所 有 守护 进程 

要 停止 本 节点 上 的 所 有 Ceph 守护 进程 ， 用 下 列 命令 : 
sudo service ceph stop 

1.3.3 按 类 型 启动 所 有 守护 进程 

要 启动 本 节点 上 的 某 一 类 Ceph 守护 进程 ， 用 下 列 命令 : 
sudo service ceph start {daemon-type} 

1.3.4 按 类 型 停止 所 有 守护 进程 

要 停止 本 节点 上 的 某 一 类 Ceph 守护 进程 ， 用 下 列 命令 : 


sudo service ceph stop {daemon-type} 

1.3.5 启动 单个 进程 

要 启动 本 节点 上 某 个 特定 的 守护 进程 例 程 ， 用 下 列 命令 : 
sudo service ceph start {daemon-type}. {instance} 
1.3.6 停止 单个 进程 
要 停止 本 节点 上 某 个 特定 的 守护 进程 例 程 ， 用 下 列 命令 : 


sudo service ceph start {daemon-type}. {instance} 


1. 操作 集群 
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2. 监控 集群 


集群 运行 起 来 后 ， 你 可 以 用 ceph 工具 来 监控 集群 的 状态 ， 典 型 的 监控 项 目 包括 
检查 OSD 状态 、monitor 的 状态 、PG ui MEMO) (目前 楚 天 云 
环境 并 没有 部 署 元 数据 服务 器 án i) 


st ak nd 
2.1 交互 模式 
要 在 交互 模式 下 运行 ceph ， 不 要 带 参 数 运行 ceph ， 例 如 : 
ceph 
ceph> health 
ceph> status 


ceph» quorum status 
ceph» mon status 


2.2 检查 集群 的 监控 状况 

启动 集群 后 、 读 写 数 据 前 ， 先 检查 下 集群 的 健康 状态 。 你 可 以 用 下 面 的 命令 检查 : 
ceph health 

如 果 你 的 配置 文件 或 keyring 文件 不 在 默认 路 径 下 ， 你 得 在 命令 中 指定 : 


ceph -c /path/to/conf -k /path/to/keyring health 


集群 刚 起 来 的 时 候 ， 你 也 许 会 碰 到 像 HEALTH WARN XXX num placement groups 
stale 这 样 的 健康 告警 ， 等 一 会 再 检查 下 。 集 群 准备 好 的 话 ceph health 会 给 
出 HEALTH OK 这 样 的 消息 ， 这 时 候 就 可 以 开始 使 用 集群 了 。 


要 观察 集群 内 正 发 生 的 事件 ， 打 开 一 个 新 终端 ， 然 后 输入 : 


ceph -w 


Ceph 会 打印 各 种 事件 。 例 如 一 个 包括 3 个 Mon ` ffe 33 个 OSD 的 Ceph 集群 可 能 
会 打印 出 这 些 : 


cluster b84b887e-9e0c-4211-8423-e0596939cd36 


health HEALTH OK 


monmap e1: 3 mons at (OPS-ceph1-192.168.219.30:6789/0,0PS-cep 
h2=192.168.219.31:6789/0, OPS-ceph3-192.168.219.32:6789/0) 
election epoch 94, quorum 0,1,2 OPS-cephi, OPS-ceph2, OP 


S-ceph3 
osdmap e1196: 33 
pgmap v1789894: 


osds: 33 up, 33 in 
2752 pgs, 7 pools, 590 GB data, 110 kobjects 


1154 GB used, 83564 GB / 84719 GB avail 
2752 activet+clean 


client io 0 B/s rd, 


2016-11-04 20:20:13. 


2752 active+clean; 
GB avail; 0 B/s rd, 


2016-11-04 20:20:15. 


2752 active+clean; 
GB avail; 0 B/s rd, 


2016-11-04 20:20:16. 


2752 active+clean; 
GB avail; 0 B/s rd, 
2016-11-04 20:20:17 

2752 active+clean; 
GB avail; 0 B/s rd, 


2016-11-04 20:20:18. 


2752 active+clean; 
GB avail; 0 B/s rd, 


2016-11-04 20:20:20. 


2752 active+clean; 
GB avail; 0 B/s rd, 


2016-11-04 20:20:21. 


2752 active+clean; 
GB avail; 0 B/s rd, 
输出 信息 里 包含 : 


e 集群 的 ID 
e 集群 健康 状况 


25852 B/s wr, 7 op/s 

682953 mon.O [INF] pgmap v1789893: 2752 pgs: 
590 GB data, 1154 GB used, 83564 GB / 84719 
44908 B/s wr, 14 op/s 

686275 mon.O [INF] pgmap v1789894: 2752 pgs: 
590 GB data, 1154 GB used, 83564 GB / 84719 
25852 B/s wr, 7 op/s 

690680 mon.O [INF] pgmap v1789895: 2752 pgs: 
590 GB data, 1154 GB used, 83564 GB / 84719 
32345 B/s wr, 16 op/s 


.694259 mon.O [INF] pgmap v1789896: 2752 pgs: 


590 GB data, 1154 GB used, 83564 GB / 84719 
57170 B/s wr, 32 op/s 
698200 mon.O [INF] pgmap v1789897: 2752 pgs: 
590 GB data, 1154 GB used, 83564 GB / 84719 
33148 B/s wr, 16 op/s 
701697 mon.O [INF] pgmap v1789898: 2752 pgs: 
590 GB data, 1154 GB used, 83564 GB / 84719 
16333 B/s wr, 5 op/s 
705719 mon.O [INF] pgmap v1789899: 2752 pgs: 
590 GB data, 1154 GB used, 83564 GB / 84719 
17705 B/s wr, 12 op/s 


e monitor map 版 本 和 mon 法 定 人 数 状态 


e OSD map 版 本 和 OSD 状态 摘要 


e PG map 版 本 
e PG 和 Pool 的 数量 


e 集群 存储 的 数据 量 ， 对 象 的 总 量 ， 以 及 集群 的 已 用 容量 /总 容量 /可 用 容量 


e 客户 端的 iops 信息 


2.4 检查 集群 的 使 用 情况 


要 检查 集群 的 数据 用 量 及 其 在 存储 池内 的 分 布 情况 ， 可 以 用 df 


上 的 gf 相似 。 如 下 : 


ceph df 


得 到 的 输出 信息 大 致 如 下 : 


GLOBAL: 
SIZE AVAIL 
84719G 83564G 
POOLS: 
NAME 
OBJECTS 
rbd 
0 
volumes 
57904 
images 
39024 
backups 
1 
vms 
4325 
volumes-ssd 
11854 
fitos backup pool 
354 


RAW USED 
1154G 

ID USED 

0 0 

1 284G 

2 224G 

3 0 

4 28736M 

5 53758M 

7 1286M 


%RAW USED 


1.36 


%USED 


输出 的 GLOBAL 段 展示 了 数据 所 占用 集群 存储 空间 的 概要 。 


选项 ， 它 和 Linux 


MAX AVAIL 


41381G 


41381G 


41381G 


41381G 


41381G 


41381G 


41381G 


e SIZE: 集群 的 总 容量 。 

e AVAIL: 集群 的 可 用 空间 总 量 。 

e RAW USED : 已 用 存储 空间 总 量 。 

e % RAW USED : 已 用 存储 空间 比率 。 用 此 值 对 比 full ratio 和 near 
full ratio 来 确保 不 会 用 尽 集 群 空间 。 


输出 的 POOLS 段 展 示 了 存储 池 列 表 及 各 存储 池 的 大 致使 用 举 。 本 段 没有 反映 出 副 
本 、 克 隆 和 快照 的 占用 情况 。 例 如 ， 如 果 你 把 1MB 的 数据 存储 为 对 象 ， 理 论 使 用 
率 将 是 1MB ， 但 考虑 到 副本 数 、 克 隆 数 、 和 快照 数 ， 实 际 使 用 量 可 能 是 2MB 或 更 
多 o 

e NAME : 存储 池 名 字 。 

e ID: 存储 池 唯 一 标识 符 。 

e USED : 大 概 数据 量 ， 单 位 为 KB 、MB X GB ; 

e %USED : 各 存储 池 的 大 概 使 用 率 。 

e Objects : 各 存储 池内 的 大 概 对 象 数 。 
注意 : POOLS 段 内 的 数字 是 估计 值 ， 它们 不 包含 副本 、 快 照 或 克隆 。 因 此 ， 各 
Pool 的 USED 和 %USED 数量 之 和 不 会 达到 GLOBAL 段 中 的 RAW USED 和 
%RAW USED 数量 。 


2.5 检查 集群 状态 

要 检查 集群 的 状态 ， 执 行 下 面 的 命令 : 
ceph Status 

A: 
ceph -s 

在 交互 模式 下 ， 输 入 status 然后 按 回 车 : 


ceph> status 


Ceph 将 打印 集群 状态 ， 例 如 一 个 包括 1 个 监视 器 、 和 2 个 OSD 的 小 型 Ceph # 
群 可 能 打印 : 


cluster b370a29d-9287-4ca3-ab57-3d824f65e339 
health HEALTH OK 
monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, 
quorum © cephi 
osdmap e63: 2 osds: 2 up, 2 in 
pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects 
115 GB used, 167 GB / 297 GB avail 
1 active+tclean+scrubbingt+deep 
951 active+clean 


2.6 检查 OSD KA 

你 可 以 执行 下 列 命令 来 确定 OSD 状态 为 up E in 
ceph osd stat 

或 者 : 
ceph osd dump 

你 也 可 以 根据 OSD 在 CRUSH MAP 里 的 位 置 来 查看 : 


ceph osd tree 


Ceph 会 打印 CRUSH # > &4& host 的 名 称 、 它 上 面 的 OSD 例 程 、 状 态 及 权重 : 


ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY -AFFINITY 


-1 0.05997 root default 

-2 0.01999 host ceph01 

0 0.01999 osd.0 up 1.00000 1.00000 
-3 0.01999 host ceph02 

1 0.01999 osd.1 up 1.00000 1.00000 
-4 0.01999 host ceph03 

2 0.01999 osd.2 up 1.00000 1.00000 


2.7 检查 Mon KA 
如 果 集 群 中 有 多 个 Mon (很 可 能 ) ， 你 启动 集群 后 、 读 写 数 据 前 应 该 检查 Mon X 


Z 
A 
定 人 数 状态 。 运 行 着 多 个 Mon 时 必须 形成 法 定 人 数 ， 最 好 周期 性 地 检查 Mon KA 
来 确定 它们 在 运行 


o 


要 查看 Mon map， 执 行 下 面 的 命令 : 
ceph mon stat 

或 者 : 
ceph mon dump 


要 检查 监视 器 的 法 定 人 数 状 态 ， 执 行 下 面 的 命 


ceph quorum status -f json-pretty 


Ceph 会 返回 法 定 人 数 状态 ， 例 如 ， 包 含 3 个 监视 器 的 Ceph 集群 可 能 返回 下 面 
的 : 


"election epoch": 94, 
"quorum": [ 
0, 
1, 
2 
] 
"quorum names": [ 
"OPS-ceph1", 
"OPS-ceph2", 
"OPS-ceph3" 
], 
"quorum leader name": "OPS-cephi", 
"monmap": { "epoch": 1, 
"fsid": "b84b887e-9e0c-4211-8423-e0596939cd36", 
"modified": "2016-11-04 20:19:57.333655", 
"created": "2016-06-23 14:53:07.171558", 
"mons": [ 
{ 
"rank": 0， 
"name": "OPS-cephi", 
"addr": "192.168.219.30:6789\/0" 


3 
{ 

"rank": 1, 

"name": "OPS-ceph2", 

"addr": "192.168.219.31:6789\/0" 
ty 
{ 

"rank": 2, 

"name": "OPS-ceph3", 

"addr": "192.168.219.32:6789\/0" 
j 


2.8 检查 MDS KA 


元 数据 服务 器 为 Ceph 文件 系统 提供 元 数据 服务 ， 不 过 在 当前 生产 环境 中 并 未 部 署 
MDS 。 元 数据 服务 器 有 两 种 状态 : up | down 和 active | inactive ， 执 
行 下 面 的 命令 查看 元 数据 服务 器 状态 为 up E active 


ceph mds stat 


要 展示 元 数据 集群 的 详细 状态 ， 执 行 下 面 的 命令 : 


ceph mds dump 


2.9 检查 PG 状态 


PG 把 对 象 映射 到 OSD 。 监 控 PG 时 ， 我 们 希望 它们 的 状态 是 active A 
clean 。 详 情 请 参考 本 手册 第 一 部 分 4. 监控 PG 


2.10 使 用 管理 套 接 字 


DURER C uq coU IT 
/var/run/ceph 下 。 要 通过 管理 套 接 字 访 问 某 个 守护 进程 ， 先 登录 它 所 在 的 主 
机 、 再 执行 下 列 命令 


ceph daemon {daemon-name} 
ceph daemon {path-to-socket- file} 


比如 ， 这 是 下 面 这 两 种 用 法 是 等 价 的 : 


ceph daemon osd.0 foo 
ceph daemon /var/run/ceph/ceph-osd.0.asok foo 


用 下 列 命令 查看 可 用 的 管理 套 接 字 命 令 : 
ceph daemon {daemon-name} help 


管理 套 接 字 命 令 允 许 你 在 运行 时 查看 和 修改 配置 


另外 ， a 可 以 在 运行 时 直接 修改 配置 选项 (也 就 是 说 管理 套 接 字 会 绕 过 Mon， 不 要 
求 你 直接 登录 宿主 主机 ， 不 像 ceph {daemon-type} tell {id} injectargs 
会 依赖 监视 器 ) 


o 


3. 监控 OSD 


X OSD 的 状态 可 以 是 在 集群 内 ( in ) 或 集群 外 ( out ) 、 也 可 以 是 运行 着 
的 ( up ) 或 不 在 运行 的 ( down ) 。 如 果 一 个 OSD 处 于 up 状态 ， 它 也 可 
以 是 在 集群 之 内 in (你 可 以 读 写 数据 ) 或 者 之 外 out 。 如 果 它 以 前 是 in 
但 最 近 out 了 ，Ceph 会 把 PG 迁移 到 其 他 OSD 上 。 如 果 某 个 OSD out 
了 ， CRUSH 就 不 会 再 分 配 PG 给 它 。 如 果 它 down 了 ， 其 状态 也 应 该 是 out 
° RUE OSD down 掉 300s 后 会 标记 它 为 out KA 


注意 : 如 果 某 个 OSD KAA down &in ， 必 定 有 问题 ， 而 且 集 群 处 于 非 健康 状 
Ao 


OSD 监控 的 一 个 重要 事情 就 是 ， 当 集群 启动 并 运行 时 ， 所 有 OSD 也 应 该 是 启动 〈 
up ) 并 在 集群 内 ( in ) 运行 的 。 用 下 列 命令 查看 : 


ceph osd stat 


其 结果 会 告诉 你 osd map 的 版 本 ( eNNNN ) ， 总 共有 多 少 个 OSD 、 几 个 是 
up 的 、 几 个 是 in 的 。 


osdmap e26753: 3 osds: 2 up, 3 in 


如 果 处 于 in KAM OSD 多 于 up 的 ， 用 下 列 命 令 看 看 哪些 ceph-osd 守护 


进程 没 在 运行 


ceph osd tree :: 


ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY 
-1 0.05997 root default 

-2 0.01999 host ceph01 

0 0.01999 osd.0 up 1.00000 1.00000 
-3 0.01999 host ceph02 

1 0.01999 osd.1 up 1.00000 1.00000 
-4 0.01999 host ceph03 

2 0.01999 osd.2 down 1.00000 1.00000 


4e XX 4 OSD 处 于 down 状态 ， 请 尝试 启动 该 OSD， 局 动 命令 见 本 手册 第 一 部 分 1. 
操作 集群 。 如 果 启 动 失败 ， 请 参考 本 手册 第 二 部 分 2. 常见 OSD 故障 处 理 中 的 相关 
部 分 进行 处 理 。 


4. 监控 PG 


CRUSH 算法 把 PG 分 配 到 OSD 时 ， 它 会 根据 存储 池 的 副本 数 设 置 ， 把 PG 分 配 

到 不 同 的 OSD 上 。 比 如 ， 如 果 存 储 池 设 置 为 3 副本 ，CRUSH 可 能 把 它们 分 别 分 
配 到 osd.1 ^ osd.2 ^ osd.3 。 考 虑 到 CRUSH Map 中 设 定 的 故障 域 ， 实 

际 上 CRUSH 找 出 的 是 伪 随 机 位 置 ， 所 以 在 大 型 集群 中 ， 很 少 能 看 到 PG 被 分 配 到 
了 相 邻 的 OSD 。 我 们 把 涉及 某 个 特定 PG 副本 的 一 组 OSD A acting set 。 在 

FERAT ' 位 于 acting set 中 的 一 个 OSD down 了 或 者 不 能 为 PG 内 的 对 象 提 
供 服 务 ， 这 些 情形 发 生 时 无 需 惊 慌 ， 常 见 原 因 如 下 : 


e 你 增加 或 移 除 了 某 个 OSD 。 然 后 CRUSH 算法 把 PG 重新 分 配 到 了 其 他 OSD 
> 因此 改变 了 Acting Set 的 构成 ， 并 且 引 发 了 “backfil” 过 程 来 进行 数据 迁移 。 
e 某 个 OSD down 了 、 重 启 了 ， 而 现在 正在 恢复 ( recovering ) ° 
e Acting Set 中 的 一 个 OSD down 了 ， 不 能 提供 服务 ， 另 一 个 OSD 临时 接替 
其 工作 。 
Ceph 3t Up Set 处 理 客户 端 请 求 ， 它 们 是 实际 处 理 读 写 请 求 的 OSD 集合 。 大 多 数 
情况 下 Up Set 和 Acting Set 是 相同 的 。 如 果 不 同 ， 说 明 可 能 Ceph 正在 迁移 数 
J£ ^ X OSD 在 恢复 、 或 者 有 别 的 问题 。 这 种 情况 下 ，Ceph 通常 表现 为 “HEALTH 
WARN" 状态 ， 还 有 “stuck stale” 消息 。 


用 下 列 命令 获取 PG 列表 : 
ceph pg dump 

查看 指定 PG 的 Acting Set 或 Up Set 中 包含 的 OSD ， 执 行 : 
ceph pg map {pg-num} 


命令 的 输出 会 告诉 你 osdmap 版 本 ( eNNN ) ^ PG 号 ( (pg-num) ) ^ Up Set 内 
( up[] ) 、 和 Acting Set A OSD ( acting[] ) ° 


osdmap e1196 pg 0.2d (0.2d) -> up [13,30] acting [13,30] 


417 点 互联 


写 入 数据 前 ，PG 必须 处 于 active 、 而 且 应 该 是 clean 状态 。 假 设 某 存储 池 
的 PG 有 3 副本 ， 为 让 Ceph 确定 PG 的 当前 状态 ，PG 的 主 OSD (F acting set 
内 的 第 一 个 OSD ) 会 与 第 二 和 第 三 OSD 建立 连接 、 并 就 PG 的 当前 状态 达成 一 

致意 见 。 


Request To 
HEN. MN" 
IE en D 
ling th 
CENE MN" 


J 


OSD 们 也 向 Mon 报告 自己 的 状态 。 要 排除 节点 互联 的 问题 ， 请 参考 本 手册 第 二 部 
分 3. 第 见 PG 故障 处 理 中 的 相关 部 分 进行 处 理 。 


4.2 监控 PG 状态 


如 果 你 执行 了 ceph health ^ ceph -s `Ñ ceph -w 命令 ， 你 也 许 注 意 到 
了 集群 并 非 总 返回 HEALTH OK 。 检 查 完 OSD 是 否 在 运行 后 ， 你 还 应 该 检查 PG 
的 状态 。 你 应 该 明白 ， 在 PG 建立 连接 时 集群 不 会 返回 HEALTH OK 


e 刚刚 创建 了 一 个 存储 池 ，PG 还 没 达成 一 致 。 
e PG 正在 恢复 。 

e 刚刚 增加 或 删除 了 一 个 OSD 。 

e 刚刚 修改 了 CRUSH Map，PG 正在 迁移 。 

e 某 一 PG 的 副本 间 的 数据 不 一 致 。 

e Ceph 正在 洗刷 一 个 PG 的 副本 。 

e Ceph 没有 足够 可 用 容量 来 完成 回填 操作 。 


如 果 是 前 述 原因 之 一 导致 了 Ceph 返回 HEALTH WARN ， 无 需 紧 张 。 很 多 情况 
下 ， 集 群 会 自行 恢复 ; 有 些 时 候 你 得 采取 些 措施 。 归 置 PG 的 一 件 重要 事情 是 保证 
集群 启动 并 运行 着 ， 所 有 PG 都 处 于 active 状态 、 并 且 最 好 是 clean 状态 。 


用 下 列 命令 查看 所 有 PG RA: 


ceph pg stat 


其 结果 会 告诉 你 PG map 的 版 本 号 ( VNNNNNN ) ^ PG 总 数 x、 有 多 少 PG 处 于 
某 种 特定 状态 ， 如 activetclean (y) œ 


VNNNNNN: x pgs: y active+clean; z MB data, aa MB used, bb MB / c 
c MB avail 


aa ada M d Ru MM ME: 间 (aa) 、 剩 余 可 用 空间 (bb 
fe PG 总 容量 。 这 些 数字 在 某 些 情况 下 是 很 重要 的 : 


e 集群 快 达到 near full ratio 或 full ratio 时 。 
e 由 于 CRUSH 配置 错误 致使 数据 没 能 在 集群 内 正确 分 布 。 


PG ID 


PG IDs 由 存储 池 号 (不 是 存储 池 名 字 ) 、 后 面 跟 一 个 点 (.) 、 再 加 一 个 16 进 制 
数字 的 PGID 。 用 ceph osd lspools 可 查看 存储 池 号 及 其 名 字 ， 例 如 ， 默 认 
存储 池 rbd 对 应 的 存储 池 号 是 0。 完 整 的 PG ID 格式 如 下 

{pool-num}.{pg-id} 
典型 例子 : 

0.1f 
用 下 列 命令 获取 PG 列表 : 

ceph pg dump 
你 也 可 以 让 它 输出 到 JSON 格式 ， 并 保存 到 文件 : 


ceph pg dump -o (filename) --format-json 


X449 X^ PG: HT: 


ceph pg {poolnum}.{pg-id} query 


Ceph 会 输出 成 JSON 格式 。 


{ 
"state": "activetclean", 
"snap trimq": "[]", 
"epoch": 26760, 
"up" : [ 
1, 
2 
], 
"acting": [ 
1, 
2 
]， 
"actingbackfill": [ 
A k 
DU 
] 
"info": { 


Wg WOL ZO 
"last update": "26708'96", 
"last complete": "26708'96", 
ogitan Ong 
"last user version": 96, 
"last backfill": "MAX", 
"purged snaps": "[1-1]", 
"history": ( 
"epoch created": 1, 
"last epoch started": 26760, 
"last epoch clean": 26760, 


"recovery state": [ 


( 


"name": "Started\/Primary\/Active", 
"enter time": "2016-11-05 11:01:12.719671", 


"might have unfound": [], 
"recovery progress": ( 
"backfill targets": [], 
"waiting on backfill": [], 
"last backfill started": "O\/\/O\/\/-1", 
"backfill info": { 
"begin": “O\/\/O\/\/-1", 
"end": CONZNZONZN SEIS 
"objects": [] 
ty 
"peer backfill info": [], 
"backfills in flight": [], 
"recovering": [], 
"pg backend": ( 
"pull from peer": [], 


"pushing": [] 
} 
ty 
bSchub N 
"scrubber.epoch_start": "26752", 
"scrubber.active": 0, 
"scrubber.waiting on": 0, 
"scrubber.waiting on whom": [] 
} 
ty 
{ 
"name": "Started", 
"enter_time": "2016-11-05 11:01:11.737126" 
j 


] 
"agent state": {} 


4.3 找 出 故障 PG 


如 前 所 述 ， 一 个 PG 状态 不 是 activetclean 时 未 必 有 问题 。 一 般 来 说 ， PG F 
住 时 Ceph 的 自修 复 功 能 可 能 会 不 起 作用 ， 卡 住 的 状态 细 分 为 : 


e Unclean: PG 里 有 些 对 象 的 副本 数 未 达到 期 望 值 ， 它 们 应 该 进行 恢复 。 


e Inactive: PG 不 能 处 理 读 写 请 求 ， 因 为 它们 在 等 着 一 个 持 有 最 新 数据 的 OSD 
回 到 up 状态 。 

e Stale: PG 处 于 一 种 未 知 状态 ， 因 为 存储 它们 的 OSD 有 一 阵子 没 向 Mon 报告 
了 (由 参数 mon osd report timeout 配置 ) » 


为 找 出 卡 住 的 归 置 组 ， 执 行 : 


ceph pg dump. stuck [unclean|inactive|stale|undersized|degraded] 


关于 排除 卡 住 的 PG 见 请 参考 本 手册 第 二 部 分 3. 常见 PG 故障 处 理 中 的 相关 部 分 
进行 处 理 。 

4.4 x Ex E TÉ 

要 把 对 象 数据 存 入 Ceph 4 KF fk > Ceph 客户 端 必 须 : 


1. 设置 对 象 名 
2. 指定 存储 池 


Ceph 客户 端 索取 最 新 集群 map、 并 用 CRUSH 算法 计算 对 象 到 PG 的 映射 ， 然 后 
计算 如 何 动态 地 把 PG 分 配 到 OSD 。 要 定位 对 象 位 置 ， 只 需要 知道 对 象 名 和 存储 
池 名 字 : 

ceph osd map {poolname} {object-name} 
练习 : 定位 一 个 对 象 


我 们 先 创建 一 个 对 象 。 给 rados put 命令 指定 一 对 象 名 、 一 个 包含 数据 的 测试 文件 
路 径 、 和 一 个 存储 池 名 字 ， 例 如 : 


rados put {object-name} {file-path} --pool-data 
rados put test-object-1 testfile.txt --pool-data 


用 下 列 命令 确认 Ceph 对 象 存储 已 经 包含 此 对 象 : 


rados -p data ls 


现在 可 以 定位 对 象 了 : 


ceph osd map {pool-name} {object-name} 
ceph osd map data test-object-1 


Ceph 应 该 输出 对 象 的 位 置 ， 例 如 : 


osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743 
484 (0.4) -» up [1,0] acting [1,0] 


要 删除 测试 对 象 ， 用 rados rm FP > 4 : 


rados rm test-object-1 --pool-data 


5. 用 户 管 理 


Ceph 把 数据 以 对 象 的 形式 存 于 各 存储 池 中 。Ceph 用 户 必 须 具 有 访问 存储 池 的 权限 
才能 够 读 写 数据 。 另 外 ，Ceph 用 户 必 须 具 有 执行 权限 才能 够 使 用 Ceph 的 管理 命 
令 o 


5.1 授权 (能 力 ) 


Ceph 用 “能 力 ”( capabilities, caps ) 这 个 术语 来 描述 给 认证 用 户 的 授权 ， 这 样 才 
能 使 用 Mon ` OSD 和 MDS 的 功能 。 能 力也 用 于 限制 对 某 一 存储 池内 的 数据 或 某 
个 命名 空间 的 访问 。 Ceph 管理 员 用 户 可 在 创建 或 更 新 普通 用 户 时 赋予 他 相应 的 能 
力 。 


能 力 的 语法 符合 下 面 的 形式 : 


{daemon-type} 'allow {capability}' [{daemon-type} 'allow {capabi 
lity}'] 


Monitor 4&7; : Monitor 能 力 包括 r ^ w ^ x 和 allow profile 
(cap) ， 例 如 : 


mon 'allow rwx' 
mon 'allow profile osd' 


OSD 能 力 : OSD 能 力 包括 r ^ w ^ x ^ class-read ^ class- 
write 和 profile osd ° A> OSD 能 力 还 支持 存储 池 和 命名 空间 的 配置 。 


osd 'allow {capability}' [pool={poolname}] [namespace={namespace 
-name}] 


MDS 能 力 : MDS 能 力 比 较 简单 ， 只 需要 allow 或 者 空白 ， 也 不 会 解析 更 多 选项 。 


mds 'allow' 


注意 : Ceph 对 象 网 关 守护 进程 ( radosgw ) 是 Ceph 存储 集群 的 一 种 客户 端 ， 
所 以 它 没 被 表示 成 一 种 独立 的 Ceph 存储 集群 守护 进程 类 型 。 


下 面 描述 了 各 种 能 力 。 
allow 


描述 : 在 守护 进程 的 访问 设置 之 前 ， 仅 对 MDS RA rw œ 


r 


描述 : 授予 用 户 读 权限 ， 对 monitor 具有 读 权 限 才 能 获取 CRUSH map ° 


W 


mut: 授予 用 户 写 对 象 的 权限 。 


wit: 授予 用 户 调用 类 方法 的 能 力 ， 即 同时 有 读 和 写 ， 且 能 在 monitor 上 执行 
auth 操作 。 


class-read 
描述 : 授予 用 户 调用 类 读 取 方法 的 能 力 ， x 的 子 集 。 
class-write 


Wi: 授予 用 户 调用 类 写 入 方法 的 能 力 ， x 的 子 集 。 


$i: 授权 此 用 户 读 、 写 和 执行 某 守护 进程 /存储 池 ， 且 允许 执行 管理 命令 。 


profile osd 


wik: 授权 一 个 用 户 以 OSD 身份 连接 其 它 OSD X Monitor » 44 P OSD 们 允许 其 它 
OSD 处 理 复 制 、 心 跳 流量 和 状态 报告 。 


profile mds 


diu: 授权 一 个 用 户 以 MDS 身份 它 MDS X, Monitor ° 


profile bootstrap-osd 


描述 : 授权 用 户 自 举 引 导 一 个 OSD a EP BRA LEA , 像 ceph-disk 、 ceph- 
deploy 等 等 ,这 样 它们 在 自 举 引导 OSD 时 就 有 权限 增加 密 钥 了 。 


profile bootstrap-mds 
描述 : 授权 用 户 自 举 引导 一 个 MDS。 授 予 例如 ceph-deploy 的 部 署 工具 ， 这 样 


它们 在 自 举 引导 MDS 时 就 有 权限 增加 密 钥 了 。 


5.2 管理 用 户 
用 户 管理 功能 可 以 让 Ceph 存储 集群 的 管理 员 有 能 力 去 创建 、 更 新 和 删除 集群 的 普 
通用 户 。 当 创建 或 删除 一 个 用 户 时 ， 可 能 需要 把 keys 分 发 给 各 客户 端 ， 以 便 它 们 
可 以 加 入 到 keyring 文件 中 。 
罗列 用 户 
可 以 使 用 下 面 的 命令 罗列 用 户 : 

ceph auth list 


Ceph 会 列 出 集群 中 的 所 有 用 户 o 例如 9 在 一 个 只 有 2 个 OSD 的 简单 环境 
T ^ ceph auth list 将 会 输入 类 似 下 面 的 内 容 : 


installed auth entries: 


osd.0 
key: AQCvCbtToC6MDhAATtuT 70S1+DymPCfDSsyV4w== 
caps: [mon] allow profile osd 
caps: [osd] allow * 

osd.1 


key: AQCACbtTCFJBChAAVq5spjOf f AeHZICXIOVZeA-- 
caps: [mon] allow profile osd 
caps: [osd] allow * 
client.admin 
key: AQBHCbtT6APDHhAA5WOOcBchwkQj h3dkKsyP jw-- 
caps: [mds] allow 
caps: [mon] allow * 
caps: [osd] allow * 
client.bootstrap-mds 
key: AQBICbtTOK9UGBAAdbe5zcIGHZL3T/u2g6EBww== 
caps: [mon] allow profile bootstrap-mds 
client.bootstrap-osd 
key: AQBHCbtTAGXqORAADE5U7RkpCN/004e5WOuBtw-- 
caps: [mon] allow profile bootstrap-osd 


注意 TYPE.ID 这 种 用 户 表示 方法 ， 比 如 osd.9 表示 用 户 类 型 是 osd EX ID 
是 9 > client.admin 表示 用 户 类 型 是 client 且 其 ID 是 admin (FPR 
认 的 client.admin AP) 。 另 外 ， 每 个 用 户 条 目 都 有 一 个 key: «value» 

对 ， 一 个 或 多 个 caps: 条 目 。 

获取 用 户 


获取 茶 一 特定 用 户 的 信息 : 


ceph auth get {TYPE. ID} 


例如 : 


ceph auth get client.admin 


还 可 以 给 命令 加 上 -o {filename} 选项 把 输入 保存 到 一 个 文件 中 。 


增加 用 户 


增加 一 个 用 户 就 是 创建 一 个 用 户 名 (BP TYPE.ID ) 、 一 个 密 钥 和 任何 包含 在 创建 
命令 中 的 能 力 。 有 以 下 几 种 方式 可 以 新 增 一 个 用 户 : 


e ceph auth add : 此 命令 是 最 权威 的 新 增 用 户 方式 。 它 回 新 建 一 个 用 户 ， 产 
生 一 个 key ， ARP Pee He o 

e ceph auth get-or-create : 这 种 方式 通常 是 最 便捷 的 一 种 ， 因 为 它 的 返回 
值 是 包含 用 户 名 (在 方 括号 内 ) 和 密 钥 的 格式 。 如 果 用 户 已 经 存在 ， 该 命令 会 
返回 密 钥 文件 格式 的 用 户 名 和 密 钥 信息 。 可 以 使 用 -o (filename) 选项 把 
输入 保存 到 一 个 文件 中 。 

e ceph auth get-or-create-key : 该 命令 可 以 很 方便 地 创建 用 户 ， 但 是 只 
会 返回 用 户 的 密 钥 。 对 于 某 些 只 需要 密 铀 的 用 户 (如 libvirt ) 来 说 是 很 有 用 
的 。 如 果 用 户 已 经 存在 ， 该 命令 仅仅 返回 用 户 的 密 钥 。 可 以 使 用 -o0 
(filename) 选项 把 输入 保存 到 一 个 文件 中 。 


下 面 是 几 个 例子 : 


ceph auth add client.john mon 'allow r' osd 'allow rw pool-liver 
pool' 

ceph auth get-or-create client.paul mon 'allow r' osd 'allow rw 
pool-liverpool' 

ceph auth get-or-create client.george mon 'allow r' osd 'allow r 
w pool-liverpool' -o george.keyring 

ceph auth get-or-create-key client.ringo mon 'allow r' osd 'allo 
w rw pool-liverpool' -o ringo.key 


修改 用 户 的 能 


ceph auth caps 命令 允许 你 指定 用 户 并 改变 用 户 的 能 力 。 设 定 新 的 能 力 会 覆盖 
当前 的 能 力 。 查 看 当前 的 能 力 可 以 使 用 ceph auth get USERTYPE.USERID ^4 
令 。 要 增加 能 力 ， 你 应 该 在 如 下 格式 的 命令 中 包含 当前 已 经 存在 的 能 力 : 


ceph auth caps USERTYPE.USERID {daemon} 'allow [r|w|x|*|...] [po 
ol={pool-name}] [namespace={namespace-name}]' [{daemon} 'allow [ 
r|w|x|*]...] [pool={pool-name}] [namespace={namespace-name}]' ] 


例如 : 


ceph auth get client.john 

ceph auth caps client.john mon 'allow r' osd 'allow rw pool-live 
rpool' 

ceph auth caps client.paul mon 'allow rw' osd 'allow rwx pool-li 
verpool' 

ceph auth caps client.brian-manager mon 'allow *' osd 'allow *' 


要 移 除 某 个 能 力 ， 你 可 能 需要 进行 重 置 。 如 果 你 想 取消 某 个 用 户 对 特定 守护 进程 的 
所 有 访问 权限 ， 可 以 指定 一 个 空 的 字符 串 。 上 比如 : 


ceph auth caps client.ringo mon ' ' osd ' ' 


Al ER JE P 


想 要 删除 一 个 用 户 ， 可 以 用 ceph auth del 命令 


ceph auth del {TYPE}. {ID} 


其 中 ， {TYPE} Æ client > osd > mon XX mds 的 其 中 一 种 。 {ID} X 
用 户 的 名 字 或 守护 进程 的 ID © 
打印 用 户 的 密 铀 


打印 某 个 用 户 的 授权 密 钥 到 标准 输出 界面 ， 可 以 执行 如 下 命令 
ceph auth print-key (TYPE).1(ID) 


日 


其 中 ， {TYPE} 是 client > osd > mon X mds 的 其 中 一 种 。 {ID} X 
用 户 的 名 字 或 守护 进程 的 ID © 

当 需 要 往 客 户 端 软 件 中 注入 Ceph AÈ (4 libvirt) 的 密 铀 时 ， 打 印 用 户 的 密 钥 时 
很 有 用 的 。 


mount -t ceph serverhost:/ mountpoint -o name=client.user,secret 
-'ceph auth print-key client.user' 


导入 用 户 


使 用 ceph auth import 命令 并 指定 密 钥 文件 ， 可 以 导入 一 个 或 多 个 用 户 : 


ceph auth import -i /path/to/keyring 


比如 : 


sudo ceph auth import -i /etc/ceph/ceph.keyring 


5.3 BA ee 
当 你 通过 客户 端 访 问 Ceph 集群 时 ，Ceph 客户 端 会 使 用 本 地 的 keyring 3c fF ° Rik 
使 用 下 列 路 径 和 名 称 的 keyring 文件 : 


e /etc/ceph/$cluster.$name.keyring 
e /etc/ceph/$cluster.keyring 

e /etc/ceph/keyring 

e /etc/ceph/keyring.bin 


你 也 可 以 在 ceph.conf 中 另行 指定 keyring 的 路 径 ， 但 不 推荐 这 样 做 。 


$cluster 元 变量 是 你 的 Ceph AEL r> RULE ceph ° $name 元 变量 
是 用 户 类 型 和 1ID 。 比 如 用 户 是 client.admin ， 那 就 得 到 


ceph.client.admin.keyring ° 


本 小 节 介绍 如 何 使 用 ceph-authtool 工具 来 从 客户 端 管理 keyring ° 


4 32 FA 


创建 一 个 空 的 keyring 文件 ， 使 用 --create-keyring 或 -C 选项 。 比 如 : 


ceph-authtool --create-keyring /path/to/keyring 


创建 一 个 包含 多 个 用 户 的 keyring 文件 ， 推 荐 使 用 $cluster.keyring 作为 文件 
名 ， 并 存放 于 /etc/ceph 目录 下 。 这 样 就 无 需 在 本 地 的 ceph.conf 文件 中 指 
定 keyring 的 路 径 了 。 


sudo ceph-authtool -C /etc/ceph/ceph.keyring 
创建 仅 包含 一 个 用 户 的 keyring 文件 时 ， 建 议 使 用 集群 名 、 用 户 类 型 和 用 户 名 称 作 
为 文件 名 ， 并 存放 于  /etc/ceph 目录 下 。 
给 密 钥 文件 中 增加 用 户 


为 了 获取 某 个 用 户 的 keyring 文件 ， 可 以 使 用 ceph auth get 命令 加 -o 3 
项 ， 以 keyring 文件 格式 来 保存 和 输出。 比如 : 


sudo ceph auth get client.admin -o /etc/ceph/ceph.client.admin.k 
eyring 


当 你 想 要 向 keyring 文件 中 导入 某 个 用 户 时 ， 可 以 使 用 ceph-authtool 来 指定 目的 和 
源 keyring 文件 。 比 如 : 


sudo ceph-authtool /etc/ceph/ceph.keyring --import-keyring /etc/ 
ceph/ceph.client.admin.keyring 


创建 用 户 


可 以 在 Ceph 客户 端 直接 创建 用 户 、 密 钥 和 人 能力。 然后 再 导入 Ceph 集群 。 比 如 : 


sudo ceph-authtool -n client.ringo --cap osd 'allow rwx' --cap m 
on 'allow rwx' /etc/ceph/ceph.keyring 


创建 keyring 文件 、 增 加 用 户 也 可 以 同时 进行 。 比 如 : 


sudo ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo --c 
ap osd 'allow rwx' --cap mon 'allow rwx' --gen-key 


Lik 7 EP > MAP clentringo 仅 存 在 于 keyring 文件 中 ， 还 需要 把 新 用 户 加 入 到 
Ceph 集群 中 。 


sudo ceph auth add client.ringo -i /etc/ceph/ceph.keyring 


修改 用 户 能 


修改 记录 在 keyring 文件 中 的 用 户 能 力 时 ， 需 要 指定 keyring 、 用 户 和 新 的 能 力 选 
Sho Fite : 


sudo ceph-authtool /etc/ceph/ceph.keyring -n client.ringo --cap 
osd ‘allow rwx' --cap mon ‘allow rwx' 


更 新 Ceph 存储 集群 的 用 户 ， 你 必须 更 新 keyring 文件 中 对 应 用 户 入 口 的 信息 。 


sudo ceph auth import -i /etc/ceph/ceph.keyring 


5.4 命令 行使 用 方法 
Ceph 支持 通过 下 列 方式 使 用 用 户 名 称 和 密 铀 。 
--id | --user 


描述 : Ceph 通过 类 型 和 ID 来 确定 用 户 ， 如 TYPE.ID 或 client.admin , 
client.useri 。 使 用 --id 或 --user 选项 指定 用 户 的 ID， 比 如 ， 指 定 使 
用 client.foo MP : 


ceph --id foo --keyring /path/to/keyring health 
ceph --user foo --keyring /path/to/keyring health 


--name | -n 


描述 : 使 用 --name 或 -n 选项 指定 用 户 的 全 名 ( TYPE.JD ) ， 比 如 : 


ceph --name client.foo --keyring /path/to/keyring health 
ceph -n client.foo --keyring /path/to/keyring health 


--keyring 
描述 : 指定 包含 一 个 或 多 个 用 户 及 其 密 钥 的 keyring 文件 路 径 。 --secret 选项 
提供 同样 的 功能 ， 但 对 Ceph RADOS Gateway 不 生效 ( --secret 选项 有 其 他 
的 作用 ) 。 比 如 : 


sudo rbd map --id foo --keyring /path/to/keyring mypool/myimage 


6. 增加 /删除 Monitor 


一 个 集群 可 以 只 有 一 个 monitor， 我 们 推荐 生产 环境 至 少 部 署 3 个 。 Ceph 使 用 
Paxos 算法 的 一 个 变种 对 各 种 map 、 以 及 其 它 对 集群 来 说 至 关 重 要 的 信息 达成 共 
识 。 建 议 (但 不 是 强制 ) 部 署 奇数 个 monitor » Ceph € € mon 中 的 大 多 数 在 运行 
并 能 够 互相 通信 ， 比 如 单个 mon， 或 2 个 中 的 2 个 ，3 个 中 的 2 个 ,4 个 中 的 3 个 
等 。 初 始 部 署 时 ， 建 议 部 署 3 个 monitor。 后 续 如 果 要 增加 ， 请 一 次 增加 2 个 。 


6.1 增加 Monitor (手动 ) 


1、 在 目标 节点 上 ， 新 建 mon 的 默认 目录 。 (mon-id) 一 般 取 为 节点 的 hostname 


o 


ssh (new-mon-host) 
sudo mkdir /var/lib/ceph/mon/ceph- {mon-id} 


2、 创 建 一 个 临时 目录 (和 第 1 步 中 的 目录 不 同 ， 添 加 mon 完毕 后 需要 删除 该 临时 
AR) ， 来 存放 新 增 mon 所 需 的 各 种 文件 ， 


mkdir {tmp} 
3、 获 取 mon 的 keyring 文件 ， 保 存在 临时 目录 下 。 
ceph auth get mon. -o {tmp}/{key-filename} 
4、 获 取 集 群 的 mon map 并 保存 到 临时 目录 下 。 
ceph mon getmap -o {tmp}/{map-filename} 


5、 格 式 化 在 第 1 步 中 建立 的 mon 数据 目录 。 需 要 指定 mon map 文件 的 路 径 ( 获 
取 法 定 人 数 的 信息 和 集群 的 fsid ) 和 keyring 文件 的 路 径 。 


sudo ceph-mon -i {mon-id} --mkfs --monmap {tmp}/{map-filename} - 
-keyring {tmp}/{key-filename} 


6、 启 动 节 点 上 的 mon 进程 ， 它 会 自动 加 入 集群 。 守 护 进 程 需要 知道 绑 定 到 哪个 |P 
地 址 ， 可 以 通过 --public-addr {ip:port} 选择 指定 ， 或 在 ceph.conf 文件 
中 进行 配置 mon addr 。 


ceph-mon -i {mon-id} --public-addr {ip:port} 


6.2 增加 Monitor ( ceph-deploy ) 
还 可 以 通过 ceph-deploy 工具 很 方便 地 增加 MON ° 


1^ €X ceph-deploy 工具 所 在 的 Ceph admin ¥ 进入 工作 目录 。 


ssh {ceph-deploy-node} 
cd /path/ceph-deploy-work-path 


2、 执 行 下 列 命令 ， 新 增 Monitor : 
ceph-deploy mon create {host-name [host-name]...) 


注意 : 在 某 一 主机 上 新 增 Mon 时 ， 如 果 它 不 是 由 ceph-deploy new 命令 所 定 
义 的 ， 那 就 必须 把 public network 加 入 ceph.conf 配置 文件 。 


6.3 删除 Monitor (手动 ) 


当 你 想 要 删除 一 个 mon 时 ， 需 要 考虑 删除 后 剩余 的 mon 个 数 是 否 能 够 达到 法 定 人 
数 。 


1、 停 止 mon 进程 。 


stop ceph-mon id={mon-id} 


2、 从 集群 中 删除 monitor ° 


ceph mon remove (mon-id) 
3、 从 ceph.conf 中 移 除 mon 的 入 口 部 分 (Je UR) ° 


6.4 删除 Monitor (从 不 健康 的 集群 中 ) 
本 小 节 介 绍 了 如 何 从 一 个 不 健康 的 集群 (比如 集群 中 的 monitor 无 法 达成 法 定 人 
数 ) 中 删除 ceph-mon 守护 进程 。 
1、 停 止 集 群 中 所 有 的 ceph-mon 守护 进程 。 

ssh {mon-host} 


service ceph stop mon || stop ceph-mon-all 
# and repeat for all mons 


2^ HiGEY mon 并 登录 该 节点 。 


ssh (mon-host) 


3 ^ 423% mon map ° 


ceph-mon -i {mon-id} --extract-monmap {map-path} 
# in most cases, that's 
ceph-mon -i "hostname! --extract-monmap /tmp/monmap 


4、 删 除 未 存活 或 有 问题 的 的 monitor » tute » A 3 * monitors > mon.a 
` mon.b 和 mon.c » MHRA mon.a 存活 ， 执 行 下 列 步 骤 : 


monmaptool {map-path} --rm {mon-id} 
# for example, 

monmaptool /tmp/monmap --rm b 
monmaptool /tmp/monmap --rm c 


5、 向 存活 的 monitor(s) 注入 修改 后 的 mon map ° Hite > de mon map 注入 
mon.a ， 执 行 下 列 步 骤 : 


ceph-mon -i {mon-id} --inject-monmap {map-path} 
# for example, 


ceph-mon -i a --inject-monmap /tmp/monmap 


6、 户 动 存活 的 monitor » 
7、 确 认 monitor 是 否 达 到 法 定 人 数 ( ceph -s ) ° 


8、 你 可 能 需要 把 已 删除 的 monitor 的 数据 目录 /var/lib/ceph/mon 归档 到 一 个 
全 的 位 置 。 或 者 ， 如 果 你 确定 剩 下 的 monitor 是 健康 的 且 数 量 足 够 ， 也 可 以 直接 
删除 数据 目录 。 


6.5 删除 Monitor ( ceph-deploy ) 


1^ AX ceph-deploy 工具 所 在 的 Ceph admin 节 进入 工作 目录 。 


ssh {ceph-deploy-node} 
cd /path/ceph-deploy-work-path 


2、 如 果 你 想 删 除 集群 中 的 某 个 Mon ， 可 以 用 destroy 选项 。 
ceph-deploy mon destroy {host-name [host-name]...} 


注意 : 确保 你 删除 某 个 Mon : X4 Mon 仍 能 达成 一 致 。 如 果 不 可 能 ， 删 除 它 之 
前 可 能 需要 先 增加 一 个 。 


7. 增加 /删除 OSD 


如 果 您 的 集群 已 经 在 运行 ， 你 可 以 在 运行 时 添加 或 删除 OSD 。 


7.1 增加 OSD (手动 ) 


要 增加 一 个 OSD， 要 依次 创建 数据 目录 、 把 硬盘 挂 载 到 数据 目录 、 把 OSD MAK 
群 、 然 后 把 它 加 入 CRUSH Map。 


up : Ceph 喜欢 统一 的 硬件 ， 与 存储 池 无 关 。 如 果 你 要 新 增 容 量 不 一 的 硬盘 驱动 
， 还 需 调 整 它们 的 权重 。 但 是 ， 为 实现 最 佳 性 能 ，CRUSH 的 分 级 结构 最 好 按 类 
型 、 容 量 来 组 织 。 


` 创建 OSD。 如 果 未 指定 UID’ OSD 启动 时 会 自动 生成 一 个 。 下 列 命令 会 输 
出 OSD 号 ， 后 续 步 骤 你 会 用 到 。 


ceph osd create [{uuid} [{id}]] 


如 果 指 定 了 可 选 参数 (id) > MA EHEH OSD id 。 要 注意 ， 如 果 此 数字 已 使 用 ， 
此 命令 会 出 错 。 

警告 : 一 般 来 说 ， 我 们 不 建议 指定 (d) 。 因 为 ID 是 按照 数组 分 配 的 ， 跳 过 一 些 依 
然 会 浪费 内 存 ; 尤其 是 跳 过 太 多 、 或 者 集群 很 大 时 ， 会 更 明显 。 若 未 指定 {fid}， 将 
用 最 小 可 用 数字 。 


2、 在 新 OSD 主机 上 创建 数据 目录 。 


ssh (new-osd-host) 
sudo mkdir /var/lib/ceph/osd/ceph- {osd-number } 


3、 如 果 准 备用 于 OSD 的 是 单独 的 磁盘 而 非 系统 盘 ， 先 把 它 挂 载 到 刚 创建 的 目录 
y 


ssh {new-osd-host} 

sudo mkfs -t {fstype} /dev/{drive} 

sudo mount -o user xattr /dev/{hdd} /var/lib/ceph/osd/ceph- {osd- 
number) 


4 ` #13614 OSD 数据 目录 。 


ssh {new-osd-host} 
ceph-osd -i {osd-num} --mkfs --mkkey 


在 启动 ceph-osd 前 ， 数据 目录 必须 是 空 的 。 


5、 注 册 OSD UWEZA > ceph-[osd-num) 路 径 里 的 ceph 值 应 该 是 
$cluster-$id ， 如 果 你 的 集群 名 字 不 是 ceph ， 那 就 用 自己 集群 的 名 字 。 


ceph auth add osd.{osd-num} osd 'allow *' mon ‘allow rwx' -i /va 
r/lib/ceph/osd/ceph- {osd-num}/keyring 


6 ^ 4247 OSD 加 入 CRUSH Map ¥ » LL. 。 用 ceph osd 
crush add 命令 把 OSD 加 入 CRUSH 分 级 结构 的 合适 。 如 果 你 指定 了 不 止 
一 个 bucket， 此 命令 会 把 它 加 入 你 所 指定 的 bucket we ' 并且 把 此 
bucket 挪 到 你 指定 的 其 它 bucket 之 内 。 


ceph osd crush add {id-or-name} {weight} [{bucket-type}={bucket- 
name} ...] 


比如 : 


ceph osd crush add 21 0.08800 pool=ssd_root rack-ssd rack01 host 
-ssd ceph4 


你 也 可 以 反 编 译 CRUSH Map » d& OSD 加 入 设备 列表 、 以 bucket 的 形式 加 入 主机 
(如 果 它 没 在 CRUSH Map €) 、 以 条 目 形式 把 设备 加 入 主机 、 分 配 权重 、 重 编译 
并 应 用 它 ， 详 情 参 见 本 手册 第 一 部 分 9. 修改 Crushmap 。 


7 ` & 35 OSD ° d£ OSD 加 入 Ceph Æ > OSD 就 在 配置 里 了 。 然 而 它 还 没 运行 ， 它 


现在 的 状态 为 down & out 。 你 必须 先 启 动 OSD EF AB 


执行 : 
sudo start ceph-osd id={osd-num} 
一 旦 你 启动 了 OSD ， 其 状态 就 变 成 了 up & in 。 


7.2 增加 OSD ( ceph-deploy ) 
还 可 以 通过 ceph-deploy 工具 很 方便 的 增加 OSD ° 


1^ €X ceph-deploy 工具 所 在 的 Ceph admin ¥ 


ssh {ceph-deploy-node} 
cd /path/ceph-deploy-work-path 


2 、 列 举 磁盘 。 


执行 下 列 命令 列举 一 节点 上 的 磁盘 : 


ceph-deploy disk list {node-name [node-name].. 


MEATUS © 


用 下 列 命 令 格式 化 (删除 分 区 表 ) 磁盘 ， 以 用 于 Ceph : 


收 数据 。 在 Ubuntu 上 


进入 工作 目录 。 


jd 


ceph-deploy disk zap {osd-server-name}: {disk-name} 


ceph-deploy disk zap osdserver1:sdb 


重要 : KAM AA LAPT ARE o 


4^ 42% OSD 。 


ceph-deploy osd prepare {node-name}: {data-disk}[:{journal-disk}] 
ceph-deploy osd prepare osdserveri:sdb:/dev/ssd 
ceph-deploy osd prepare osdserveri:sdc:/dev/ssd 


prepare 命令 只 准备 OSD 。 在 大 多 数 操作 系统 中 ， 硬 盘 分 区 创建 后 ， 不 用 
activate 命令 也 会 自动 执行 activate 阶段 (通过 Ceph 的 udev 规则 ) 。 


前 例假 定 一 个 硬盘 只 会 用 于 一 个 OSD 守护 进程 ， 以 及 一 个 到 SSD 日 志 分 区 的 路 
和 对。 我 们 建议 把 日 志 存 储 于 另外 的 驱动 器 以 最 优化 性 能 ; 你 也 可 以 指定 一 单独 的 驱 
动 器 用 于 日 志 (eH) 、 或 者 把 日 志 放 到 OSD XE X (不 建议 ， 因 为 它 
有 损 性 能 ) 。 前 例 中 我 们 把 日 志 存 储 于 分 好 区 的 固态 硬盘 。 


注意 : 在 一 Tops 运行 多 个 OSD 守护 进程 、 且 多 个 OSD 守护 进程 共享 一 个 日 志 
分 区 时 ， 你 应 该 考虑 整个 节 EL CRUSH 故障 域 ， 因 为 如 果 这 个 SSD KT > 
所 有 用 其 做 日 志 的 OSD Pond 并 程 也 会 失效 。 


5、 准 备 好 OSD 后 ， 可 以 用 下 列 命令 激活 它 。 


ceph-deploy osd activate {node-name}: {data-disk-partition}[:{jou 
rnal-disk-partition)] 

ceph-deploy osd activate osdserver1:/dev/sdb1:/dev/ssd1 
ceph-deploy osd activate osdserver1:/dev/sdc1:/dev/ssd2 


activate 44 iE OSD 进入 up E in 状态 。 该 命令 使 用 的 分 区 路 径 是 
面 prepare 命令 创建 的 。 


7.3 BI OSD (手动 ) 


要 想 缩减 集群 尺寸 或 替换 硬件 ， 可 在 运行 时 删除 OSD 。 在 Ceph 里 ， 一 个 OSD 通 
常 是 一 台 主 机 上 的 一 个 ceph-osd 守护 进程 、 它 运行 在 一 个 硬盘 之 上 。 如 果 一 台 
主机 上 有 多 个 数据 盘 ， 你 得 逐个 删除 其 对 应 ceph-osd 。 通 常 ， 操 作 前 应 该 检查 
集群 容量 ， 看 是 否 快 达到 上 限 了 ， 确 保 删 除 OSD 后 不 会 使 集群 达到 near full 
比率 o 


警告 : 删除 OSD 时 不 要 让 集群 达到 full ratio (4° 删除 OSD 可 能 导致 集群 
达到 或 超过 full ratio 值 。 


q^ ii aie 除 的 OSD 进程 ， 让 其 他 的 OSD 知道 这 个 OSD 不 提供 服务 了 。 停 
x+ OSD 后 ， 状 态 变 为 down ° 


ssh {osd-host} 
sudo stop ceph-osd id={osd-num} 


2^ 4$ OSD 标记 为 out 状态 ， 这 个 一 步 是 告诉 mon? ix^ OSD 已 经 不 能 服务 
了 ， 需 要 在 其 他 的 OSD 上 进行 数据 的 均衡 和 恢复 了 。 


ceph osd out {osd-num} 
执行 完 这 一 步 后 ， 会 触发 数据 的 恢复 过 程 。 此 时 应 该 等 待 数据 恢复 结束 ， 集 群 恢复 
到 HEALTH OK 状态 ， 再 进行 下 一 步 操 作 。 


3^ AR CRUSH Map 中 的 对 应 OSD 条 目 ， 它 就 不 再 接收 数据 了 。 你 也 可 以 反 编 

译 CRUSH Map ` Jil device 列表 条 目 、 删 除 对 应 的 host 桶 条 目 或 删除 host 4 
bubo Oed PA RM 而 且 你 想 删除 主机 ) ， 重 编译 CRUSH Map 并 应 用 
它 。 详 情 参 见 本 手册 第 一 部 分 9. 修改 Crushmap 。 


ceph osd crush remove (name) 


该 步骤 会 触发 数据 的 重新 分 布 。 等 待 数 据 重 新 分 布 结束 ， 整 个 集群 会 恢复 到 
HEALTH OK 状态 。 


4 > BIE OSD GERA : 


ceph auth del osd.{osd-num} 


5^ MR OSD 。 


ceph osd rm {osd-num} 
#for example 
ceph osd rm 1 


6^ #7 4% OSD 的 挂 载 点 。 


sudo umount /var/lib/ceph/osd/$cluster - {osd-num} 


7、 和 登录 到 保存 ceph.conf £4 Jide 


ssh {admin-host} 
cd /etc/ceph 
vim ceph.conf 


8^ Jk. ceph.conf 配置 文件 里 删除 对 应 条 目 。 


[osd.1] 
host - (hostname) 


9、 从 保存 ceph.conf 主 拷贝 的 主机 ， 把 更 新 过 的 ceph.conf 拷贝 到 集群 其 
他 主机 的 /etc/ceph 目录 下 。 


如 果 在 ceph.conf 中 没有 定义 各 OSD 入 口 ， 就 不 必 执 行 第 7~9 步 。 


8. 操作 Pool 


如 果 你 开始 部 署 集群 时 没有 创建 存储 池 ，Ceph 会 用 默认 存储 池 rbd 存放 数据 。 存 
储 池 提供 的 功能 : 


e EX ZI: 你 可 以 设置 在 不 丢 数 据 的 前 提 下 允许 多 少 OSD 失效 。 对 多 副本 存 
储 池 来 说 ， 此 值 是 一 对 得 应 达到 的 副本 数 。 典 型 配置 是 存储 一 个 对 象 和 它 的 一 
个 副本 (BP size = 2 ) ， 但 你 可 以 更 改 副本 数 ; 对 纠 删 编码 的 存储 池 来 说 ， 此 
值 是 编码 块 数 ( 即 纠 删 码 配置 里 的 m=2) © 

e 归 置 组 : 你 可 以 设置 一 个 存储 池 的 PG 数量 。 典 型 配置 给 每 个 OSD 分 配 大 约 
100 个 PG， 这 样 ， 不 用 过 多 计算 资源 就 能 得 到 较 优 的 均衡 。 配 置 了 多 个 存储 
池 时 ， 要 考虑 到 这 些 存储 池 和 整个 集群 的 PG 数量 要 合理 。 

e CRUSH 规则 : 当 你 在 存储 池 里 存 数 据 的 时 候 ， 与 此 存储 池 相 关联 的 CRUSH 
规则 集 可 控制 CRUSH 算法 ， 并 以 此 操纵 集群 内 对 象 及 其 副本 的 复制 (或 纠 删 
码 编码 的 存储 池 里 的 数据 块 )。 你 可 以 自 定义 存储 池 的 CRUSH 规则 。 

e 快照 : 用 ceph osd pool mksnap 创建 快照 的 时 候 ， 实 际 上 创建 了 某 一 特 
定 存储 池 的 快照 。 


要 把 数据 组 织 到 存储 池 里 ， 你 可 以 列 出 、 创 建 、 删 除 存 储 池 ， 也 可 以 查看 每 个 存储 
池 的 使 用 统计 数据 。 


8.1 列 出 存储 池 
要 列 出 集群 的 存储 池 ， 命 令 如 下 : 
ceph osd lspools 
在 新 安装 好 的 集群 上 ， 上 默认 只 有 一 个 rbd 存储 池 。 


8.2 创建 存储 池 


创建 存储 池 前 可 以 先 看 看 存储 池 、PG 和 CRUSH 配置 参考 。 你 最 好 在 配置 文件 里 
重 置 默 认 PG 数量 ， 因 为 默认 值 并 不 理想 。 


例如 : 


osd pool default pg num = 100 
osd pool default pgp num - 100 


要 创建 一 个 存储 池 ， 执 行 : 


ceph osd pool create {pool-name} {pg-num} [{pgp-num}] [replicate 
d] N 
[crush-ruleset-name] [expected-num-objects] 
ceph osd pool create {pool-name} {pg-num} {pgp-num} erasure \ 
[erasure-code-profile] [crush-ruleset-name] [expected_nu 
m objects] 


e (pool-name) : 存储 池 名 称 ， 必 须 唯一 。 

e [pg num) : 存储 池 的 PG 数目 。 

e (pgp num) : 存储 池 的 PGP 数目 ， 此 值 应 该 和 PG 数目 相等 。 

e {replicated|erasure} : 存储 池 类 型 ， 可 以 是 副本 池 (保存 多 份 对 象 副 
本 ， 以 便 从 丢失 的 OSD 恢复 ) RAM (REŽA RAIDS 的 功能 ) 。 多 副本 
存储 池 需 更 多 原始 存储 空间 ， 但 已 实现 所 有 Ceph 操作 ; 纠 删 存储 池 所 需 原 始 
存储 空间 较 少 ， 但 目前 仅 实现 了 部 分 Ceph 操作 。 

e [crush-ruleset-name] : 此 存储 池 所 用 的 CRUSH 规则 集 名 字 。 指 定 的 规 

则 集 必 须 存在 。 对 于 多 副本 (replicated ) 存储 池 来 说 ， 其 默认 规则 集 由 

osd pool default crush replicated ruleset 配置 决定 ， 此 规则 集 必 须 

存在 。 对 于 用 erasure-code 编码 的 纠 删 码 〈 erasure ) 存储 池 来 说 ， 不 

同 的 {pool-name} 所 使 用 的 默认 ( default ) 纠 删 码 配置 是 不 同 的 ， 如 

果 它 不 存在 的 话 ， 会 显 式 地 创建 它 。 

[erasure-code-profile-profile] : 仅 用 于 纠 删 存储 池 。 指 定 纠 删 码 配置 
文件 ， 此 配置 必须 已 由 osd erasure-code-profile set 定义 。 

e [expected-num-objects] :为 这 个 存储 池 预 估 的 对 象 数 。 设 置 此 和 值 (要 同 
时 把 filestore merge threshold 设置 为 负数 ) 后 ， 在 创建 存储 池 时 就 会 拆 分 
PG 文件 夹 ， 以 免 运 行 时 拆 分 文件 夹 导 致 延 时 增 大 。 


关于 如 何 计 算 合 适 的 pg num 值 ， 可 以 使 用 Ceph 官方 提供 的 一 个 计算 工具 
pgcalc ° 


8.3 设置 存储 池 配 额 
存储 池 配 额 可 设置 最 大 字 节 数 、 和 /或 每 个 存储 池 最 大 对 象 数 。 


ceph osd pool set-quota {pool-name} [max objects {obj-count}] [m 
ax bytes {bytes}] 


例如 : 
ceph osd pool set-quota data max_objects 10000 
要 取消 配额 ， 设 置 为 0 即 可 。 
8.4 删除 存储 池 
要 删除 一 存储 池 ， 执 行 : 


ceph osd pool delete {pool-name} [{pool-name} --yes-i-really-rea 
lly-mean-it] 


如 果 你 给 自 建 的 存储 池 创 建 了 定制 的 规则 集 ， 你 不 需要 存储 池 时 最 好 也 删除 规则 
集 o 


ceph osd pool get {pool-name} crush ruleset 
加 入 规则 和 集 是 “123”， 可 以 这 样 选择 存储 池 : 


ceph osd dump | grep "^pool" | grep "crush ruleset 123" 


如 果 你 曾 严格 地 创建 了 用 户 及 其 权限 给 一 个 存储 池 ， 但 存储 池 已 不 存在 ， 最 好 也 删 
除 那 些 用 户 。 


ceph auth list | grep -C 5 {pool-name} 
ceph auth del {user} 


8.5 重 命名 存储 池 
要 重 命 名 一 个 存储 池 ， 执 行 : 


ceph osd pool rename {current-pool-name} {new-pool-name} 


如 果 重 命名 了 一 个 存储 池 ， 且 认证 用 户 对 每 个 存储 池 都 有 访问 权限 ， 那 你 必须 用 新 
存储 池 名 字 更 新 用 户 的 能 力 〈 即 caps) 。 


8.6 查看 存储 池 统 计 信 息 
要 查看 某 存储 池 的 使 用 统计 信息 ， 执 行 命令 : 


rados df 


8.7 给 存储 池 做 快照 
要 给 某 存 储 池 做 快照 ， 执 行 命 令 : 


ceph osd pool mksnap {pool-name} {snap-name} 


8.8 删除 存储 池 的 快照 
要 删除 某 存 储 池 的 一 个 快照 ， 执 行 命 令 : 


ceph osd pool rmsnap {pool-name} {snap-name} 


8.9 获取 存储 池 选 项 值 


要 获取 一 个 存储 池 的 选项 值 ， 执行 命令 : 


ceph osd pool get {pool-name} {key} 


8.10 调整 存储 池 选 项 值 


要 设置 一 个 存储 池 的 选项 值 ， 执行 命令 : 
ceph osd pool set {pool-name} {key} {value} 


常用 选项 介绍 : 


e size : 设置 存储 池 中 的 对 象 副 本 数 ， 详 情 参 见 设置 对 象 副本 数 。 仅 适用 于 副 
本 存储 池 。 

e min size :设置 |/O 需要 的 最 小 副本 数 ， 详 情 参 见 设置 对 象 副 本 数 。 仅 适用 
于 副本 存储 池 。 

e pg num : 计算 数据 分 布 时 的 有 效 PG 数 。 只 能 大 于 当前 PG 数 。 

e pgp_num : 计算 数据 分 布 时 使 用 的 有 效 PGP 数量 。 小 于 等 于 存储 池 的 PG 
数 。 

e crush ruleset 

e hashpspool : 给 指定 存储 池 设 置 / 取 消 HASHPSPOOL 标志 。 

e target max bytes :达到 max bytes JAAN SARA Ceph % ARRA 
象 o 

e target max objects :达到 max objects fA AAR RK Ceph 冲洗 或 驱 
IT Ho 

e scrub min interval :在 负载 低 时 ， 洗 刷 存储 池 的 最 小 间隔 秒 数 。 如 果 是 
0 ， 就 按照 配置 文件 里 的 osd_scrub_min_interval 。 

e scrub max interval : 不 管 集群 负载 如 何 ， 都 要 洗刷 存储 池 的 最 大 间隔 秒 
数 。 如 果 是 0 ， 就 按照 配置 文件 里 的 osd_scrub_max_interval 。 

e deep scrub interval : “深度 "洗刷 存储 池 的 间隔 秒 数 。 如 果 是 0 ， 就 按照 
配置 文件 里 的 osd deep scrub interval ° 


8.11 i£ E E SA 
要 设置 多 副本 存储 池 的 对 象 副 本 数 ， 执 行 命 


ceph osd pool set {poolname} size {num-replicas} 


重要 : {num-replicas} 包括 对 象 自 身 ， 如 果 你 想 要 对 象 自身 及 其 两 份 捞 贝 共计 
三 份 ， 指 定 size 为 3。 


例如 : 


ceph osd pool set data size 3 


你 可 以 在 每 个 存储 池上 执行 这 个 命令 。 注 意 ， 一 个 处 于 降级 模式 的 对 象 ， 其 副本 数 
小 于 pool size ， 但 仍 可 接受 |/O 请 求 。 为 保证 VOL > TA min size 选 
项 为 其 设置 个 最 低 副本 数 。 例 如 : 


ceph osd pool set data min size 2 
这 确保 数据 存储 池 里 任何 副本 数 小 于 min size 的 对 象 都 不 会 收 到 I/O T ° 
8.12 RR A e| AX 
要 获取 对 象 副本 数 ， 执 行 命令 : 


ceph osd dump | grep 'replicated size' 


Ceph SF) ££ fee > HA % replicated size 属性 。 默 认 情 况 下 ，Ceph 会 创 
建 一 对 象 的 两 个 副本 《一 共 三 个 副本 ， 或 Size 值 为 3 ) 。 


9. 管理 Crushmap 


CRUSH 算法 通过 计算 数据 存储 位 置 来 确定 如 何 存储 和 检索 。 CRUSH 授权 Ceph 
客户 端 直 接连 接 OSD ， 而 非 通 过 一 个 中 央 服 务 器 或 代理 。 数 据 存储 、 检 索 算 法 的 
使 用 ， 使 Ceph 避免 了 单 点 故障 、 性 能 瓶 开 、 和 伸缩 的 物理 限制 。 


CRUSH 需要 一 张 集群 的 Map， 且 使 用 CRUSH Map 把 数据 伪 随 机 地 、 尽 量 平均 地 
分 布 到 整个 集群 的 OSD 里 。CRUSH Map 包含 OSD 列表 、 把 设备 汇聚 为 物理 位 
置 的 “ 桶 "列表 、 和 指示 CRUSH 如 何 复制 存储 池 里 的 数据 的 规则 列表 。 


完全 手动 管理 CRUSH Map 也 是 可 能 的 ， 在 配置 文件 中 设 定 : 


osd crush update on start = false 


9.1 编辑 CRUSH Map 


要 编辑 现 有 的 CRUSH Map : 


获取 CRUSH Map : 

反 编 译 CRUSH 图 : 

至 少 编辑 一 个 设备 、 桶 、 规 则 ; 
重 编译 CRUSH Map : 

注入 CRUSH Map ° 


oe 2 wol» 


要 激活 CRUSH Map XX £r f AML > 251 :8 70 2] Ras > Katee d8 x FI Ap 
个 规则 集 。 详 情 参见 本 手册 第 一 部 分 8. 操作 Pool 中 调整 存储 池 选 项 值 部 分 。 


获取 CRUSH Map 


要 获取 集群 的 CRUSH Map， 执 行 命令 : 


ceph osd getcrushmap -o {compiled-crushmap- filename} 


Ceph 将 把 CRUSH 输出 〈 -o ) 到 你 指定 的 文件 ， 由 于 CRUSH Map 是 已 编译 
的 ， 所 以 编辑 前 必须 先 反 编译 。 


反 编 译 CRUSH Map 
要 反 编 译 CRUSH Map， 执 行 命令 : 


crushtool -d {compiled-crushmap-filename} -o {decompiled-crushma 
p-filename} 


Ceph 将 反 编译 ( -d ) 二 进 制 CRUSH Map， 且 输出 〈-o ) 到 你 指定 的 文件 。 
编译 CRUSH Map 
要 编译 CRUSH Map， 执 行 命令 : 


crushtool -c {decompiled-crush-map-filename} -o {compiled-crush- 
map-filename) 


Ceph 将 把 已 编译 的 CRUSH Map 保存 到 你 指定 的 文件 。 
注入 CRUSH Map 


要 把 CRUSH Map 应 用 到 集群 ， 执 行 命令 : 


ceph osd setcrushmap -i {compiled-crushmap-filename} 
Ceph 将 把 你 指定 的 已 编译 CRUSH Map 注入 到 集群 。 


9.2 CRUSH Map 参数 
CRUSH Map 主要 有 4 个 段落 。 


1. 设备 : 由 任意 对 象 存储 设备 组 成 ， 即 对 应 一 个 ceph-osd 进程 的 存储 器 。 
Ceph 配置 文件 里 的 每 个 OSD 都 应 该 有 一 个 设备 。 

2. 桶 类 型 : 定义 了 CRUSH 分 级 结构 里 要 用 的 桶 类 型 ( types ) ， 桶 由 逐 级 
汇聚 的 存储 位 置 (如 行 、 机 柜 、 机 箱 、 主 机 等 等 ) 及 其 权重 组 成 。 

3. 桶 实例 : 定义 了 桶 类 型 后 ， 还 必须 声明 主机 的 桶 类 型 、 以 及 规划 的 其 它 故障 
A 

4. 规则 : 由 选择 桶 的 方法 组 成 。 


CRUSH Map 之 设备 


为 把 PG 映射 到 OSD > CRUSH Map 需要 OSD 列表 〈 即 配置 文件 所 定义 的 OSD 
守护 进程 名 称 ) ， 所 以 它们 首先 出 现在 CRUSH Map 里 。 要 在 CRUSH Map 里 声 
明 一 个 设备 ， 在 设备 列表 后 面 新 建 一 行 ， 输 入 device 、 之 后 是 唯一 的 数字 ID ` 
之 后 是 相应 的 ceph-osd 守护 进程 实例 名 字 。 


# devices 
device {num} {osd.name} 


例如 : 


# devices 

device 0 osd.0 
device 1 osd.1 
device 2 osd.2 
device 3 osd.3 


CRUSH Map 之 桶 类 型 


CRUSH Map 里 的 第 二 个 列表 定义 了 bucket ( 桶 ) 类 型 ， 桶 简化 了 节点 和 叶子 层 
次 。 节 点 (或 非 叶子 ) 桶 在 分 级 结构 里 一 般 表示 物理 位 置 ， 节 点 汇聚 了 其 它 节点 或 
叶子 ， 叶 桶 表示 ceph-osd 守护 进程 及 其 对 应 的 存储 媒体 


要 往 CRUSH Map 中 增加 一 种 bucket 类 型 ， 在 现 有 桶 类 型 列表 下 方 新 增 一 行 ， 输 
入 type 、 之 后 是 惟一 数字 ID 和 一 个 桶 名 。 按 惯例 ， 会 有 一 个 叶子 桶 为 type 
O ， 然 而 你 可 以 指定 任何 名 字 (如 osd ^ disk ^ drive ^ storage 等 等 ) 


4 types 
type {num} {bucket-name} 


例如 : 


# types 


type 0 osd 

type 1 host 

type 2 chassis 
type 3 rack 

type 4 row 

type 5 pdu 

type 6 pod 

type 7 room 

type 8 datacenter 
type 9 region 


type 10 root 


CRUSH Map 之 桶 层次 


CRUSH 算法 根据 各 设备 的 权重 、 大 致 统一 的 概率 把 数据 对 象 分 布 到 存储 设备 中 。 
CRUSH 根据 你 定义 的 集群 运行 图 分 布 对 象 及 其 副本 ，CRUSH Map 表达 了 可 用 存 
储 设备 以 及 包含 它们 的 逻辑 单元 。 


要 把 PG 映射 到 跨 故 障 域 的 OSD ， 一 个 CRUSH Map 需 定义 一 系列 分 级 桶 类 型 

(Fp3LZ CRUSH Map 的 # type T) 。 创 建 桶 分 级 结构 的 目的 是 按 故障 域 隔离 
叶子 节点 ， 像 主机 、 机 箱 、 机 柜 、 电 力 分 配音 元、 机群 、 行 、 房 间 、 和 数据 中 心 。 
除了 表示 叶子 节点 的 OSD ， 其 它 分 级 结构 都 是 任意 的 ， 你 可 以 按 需 定义 。 


声明 一 个 桶 实例 时 ， 你 必须 指定 其 类 型 、 惟 一 名 称 CRAP) 、 惟 一 负 整 数 ID 
(T) 、 指 定 和 各 条 目 总 容量 /能 力 相 关 的 权重 、 指 定 桶 算法 (通常 是 straw) ^ 

和 哈 希 (通常 为 0， 表 示 哈 希 算 法 rjenkins1 ) 。 一 个 桶 可 以 包含 一 到 多 个 条 目 ， 
这 些 条 目 可 以 由 节点 桶 或 叶子 组 成 ， 它 们 可 以 有 个 权重 用 来 反映 条 目的 相对 权重 。 


你 可 以 按 下 列 语法 声明 一 个 节点 桶 : 


[bucket-type] [bucket-name] { 
id [a unique negative numeric ID] 
weight [the relative capacity/capability of the item(s)] 
alg [the bucket type: uniform | list | tree | straw ] 
hash [the hash type: 0 by default] 
item [item-name] weight [weight] 


例如 ， 我 们 可 以 定义 两 个 主机 桶 和 一 个 机 柜 桶 ， 机 柜 桶 包含 两 个 主机 桶 ，OSD 被 
声明 为 主机 桶 内 的 条 目 : 


host node1 { 
id -1 
alg straw 
hash 0 
item osd.0 weight 1.00 
item osd.1 weight 1.00 


} 

host node2 { 
id -2 
alg straw 
hash 0 


item osd.2 weight 1.00 
item osd.3 weight 1.00 


} 
rack rack1i ( 
id -3 
alg straw 
hash 0 


item node1 weight 2.00 
item node2 weight 2.00 


调整 桶 的 权重 


Ceph 用 双 精 度 类 型 数据 表示 桶 权重 。 权 重 和 设备 容量 不 同 ， 我 们 建议 用 1.00 作为 
1TB 存储 设备 的 相对 权重 ， 这 样 0.5 的 权重 大 概 代表 500GB 、3.00 AMARA 3TB 
。 较 高 级 桶 的 权重 是 所 有 叶子 桶 的 权重 之 和 。 


一 个 桶 的 权重 是 一 维 的 ， 你 也 可 以 计算 条 目 权 重 来 反映 存储 设备 性 能 。 例 如 ， 如 果 
你 有 很 多 1TB 的 硬盘 ， 其 中 一 些 数 据 传输 速率 相对 低 、 其 他 的 数据 传输 牵 相 对 高 ， 
即使 它们 容量 相同 ， 也 应 该 设置 不 同 的 权重 (如 给 吞吐 量 较 低 的 硬盘 设置 权重 0.8 
， 较 高 的 设置 1.20 ) 。 


CRUSH Map 之 规则 


CRUSH Map X 4$^ CRUSH 规则 ”的 概念 ， 用 以 确定 一 个 存储 池 里 数据 的 分 布 。 
CRUSH 规则 定义 了 归 置 和 复制 策略 、 或 分 布 策略 ， 用 它 可 以 规定 CRUSH 如 何 放 
置 对 象 副本 。 对 大 型 集群 来 说 ， 你 可 能 创建 很 多 存储 池 ， 且 每 个 存储 池 都 有 它 自己 
的 CRUSH 规则 集 和 规则 。 默 认 的 CRUSH Map 里 ， 每 个 存储 池 有 一 条 规则 、 一 
个 规则 集 被 分 配 到 每 个 默认 存储 池 。 


REG 大 多 数 情 况 下 ， 你 都 不 需要 修改 默认 规则 。 新 创建 存储 池 的 默认 规则 集 是 
[9] o 


规则 格式 如 下 
rule <rulename> { 


ruleset <ruleset> 

type [ replicated | erasure ] 

min_size <min-size> 

max size <max-size> 

step take «bucket-type» 

step [choose|chooseleaf] [firstn|indep] «N» «bucket-type 


step emit 


参数 说 明 : 


e ruleset : 区 分 一 条 规则 属于 某 个 规则 集 的 手段 。 给 存储 池 设 置 规则 集 后 激 
活 。 

e type :规则 类 型 ， 目 前 仅 支 持 replicated 和 erasure ， 默 认 是 
replicated ° 

e min size : 可 以 选择 此 规则 的 存储 池 最 小 副本 数 。 

e max size : 可 以 选择 此 规则 的 存储 池 最 大 副本 数 。 

e step take <bucket-name> : 选取 起 始 的 桶 名 ， 并 和 迭代 到 树 底 。 

e step choose firstn {num} type {bucket-type} : 选取 指定 类 型 桶 的 数 
量 ， 这 个 数字 通常 是 存储 池 的 副本 数 (PP pool size ) 。 如 果 {num} == 0 
， 选 择 pool-num-replicas 个 桶 (所 有 可 用 的 ) ;如 果 {num} > 0 && < 
pool-num-replicas ， 就 选择 那么 多 的 桶 ; 如 果 {num} < 0 ， 它 意味 着 选 
择 pool-num-replicas - (num) 个 桶 。 


e step chooseleaf firstn {num} type {bucket-type} : 选择 {bucket- 


type) 类 型 的 桶 集合 ， 并 从 各 桶 的 子 树 里 选择 一 个 叶子 节点 。 桶 集合 的 数量 
通常 是 存储 池 的 副本 数 (FP pool size ) 。 如 果 {num} == © ， 选 择 pool- 
num-replicas 个 桶 (所 有 可 用 的 ) ;如 果 {num} > 0 && < pool-num- 
replicas ， 就 选择 那么 多 的 桶 ; 如 果 {num} < 9 ， 它 意味 着 选择 pool- 
num-replicas - {num} 个 桶 。 

e step emit :输出 当前 值 并 清空 堆栈 。 通 常用 于 规则 末尾 ， 也 适用 于 相同 规 
则 应 用 到 不 同 树 的 情况 。 


9.3 主 杀 和 性 


ŽA Ceph 客户 端 读 写 数据 时 ， 总 是 连接 acting set 里 的 主 OSD (如 [2, 3, 

4] 中 ， osd.2 是 主 的 ) 。 有 时 候 某 个 OSD 与 其 它 的 相 比 并 不 适合 做 主 OSD 
(比如 其 硬盘 慢 、 或 控制 器 慢 ) 。 最 大 化 硬件 利用 率 时 为 防止 性 能 瓶颈 (特别 是 读 
操作 ) ， 你 可 以 调整 OSD 的 主 亲 和 性 ， 这 样 CRUSH 就 尽量 不 把 它 用 作 acting set 

里 的 主 OSD 了 。 


ceph osd primary-affinity «osd-id» «weight» 


主 亲 和 性 默认 为 1 (就 是 说 此 OSD 可 作为 主 OSD ) 。 此 值 合法 范围 为 0-1 
， 其 中 o 意 为 此 OSD 不 能 用 作 主 的 ， 1 BA OSD 可 用 作 主 的 。 此 权重 < 
1 时 ，CRUSH 选择 主 OSD 时 选中 它 的 可 能 性 就 较 低 。 


9.4 增加 /移动 OSD 


要 增加 或 移动 在 线 集群 里 OSD 所 对 应 的 CRUSH Map 条 目 ， 执行 ceph osd crush 
set 命令 。 


ceph osd crush set {id-or-name} {weight} {bucket-type}={bucket-n 
ame? [{bucket-type}={bucket-name} ...] 


9.5 调整 OSD 的 CRUSH 权重 


要 调整 在 线 集群 中 某 个 OSD 的 CRUSH 权重 ， 执 行 命 令 : 


ceph osd crush reweight {name} {weight} 


9.6 删除 OSD 


要 从 在 线 集群 里 把 某 个 OSD 彻底 踢 出 CRUSH Map， 或 仅 踢 出 某 个 指定 位 置 的 
OSD， 执 行 命 令 : 


ceph osd crush remove (name) («ancestor») 


9.7 增加 桶 


要 在 运行 集群 的 CRUSH Map 中 新 建 一 个 桶 ， 用 ceph osd crush add-bucket 4» 


a: 


ceph osd crush add-bucket {bucket-name} {bucket-type} 
9.8 1$ zh 78 
要 把 一 个 桶 移动 到 CRUSH Map 里 的 不 同位 置 ， 执 行 命令 : 


ceph osd crush move {bucket-name} {bucket-type}={bucket-name} [1 
bucket-type}={bucket-name} ...] 


9.9 删除 桶 
要 把 一 个 桶 从 CRUSH Map 的 分 级 结构 中 删除 ， 可 用 此 命令 : 
ceph osd crush remove {bucket-name} 


注意 : 从 CRUSH 分 级 结构 里 删除 时 必须 是 空 桶 。 


9.10 可 人 调 选项 


从 v0.74 起 ， 如 果 CRUSH 值 ( v0.73 版 里 的 默认 值 ) Ceph 就 
会 发 出 健康 告警 ， 有 两 种 方法 可 消除 这 些 告 警 


1、 调 整 现 有 集群 上 的 可 调 选项 。 注 意 ， 这 可 能 会 导致 一 些 数据 迁移 (可 能 有 1096 
job eU ML Hc Ed R xu o th 
命令 可 启用 较 优 可 调 选 


ceph osd crush tunables optimal 


如 果 切 换 得 不 太 顺 利 (如 负载 太 高 ) 且 切 换 才 不 久 ， 或 者 有 客户 端 兼容 问题 (E 
的 cephfs 内 核 驱 动 或 rbd 客户 端 、 或 早 于 bobtail 的 librados 客户 端 ) ， 你 可 以 这 
样 切 回 : 


ceph osd crush tunables legacy 


2^ Rat CRUSH 做 任何 更 改 也 能 消除 报警 ， 把 下 列 配置 加 入 ceph.conf 的 
[mon] 段 下 : 


mon warn on legacy crush tunables = false 


为 使 变更 生效 需 重 局所 有 监视 器 ， 或 者 执行 下 列 命令 : 


ceph tell mon.\* injectargs --no-mon-warn-on-legacy-crush-tunabl 
es 


9.11 CRUSH Map 实例 


假设 你 想 让 大 多 数 存 储 池 映射 到 使 用 大 容量 硬盘 的 OSD 上 ， 但 是 其 中 一 些 存储 池 
映射 到 使 用 高 速 SSD 的 OSD 上 。 在 同一 个 CRUSH Map 内 有 多 个 独立 的 
CRUSH 层级 结构 是 可 能 的 ， 定 义 两 棵 树 、 分 别 有 自 己 的 根 节点 一 一 一 个 用 于 机 械 
硬盘 (如 rootplatter ) 、 一 个 用 于 SSD (+ root ssd ) ， 具 体 的 CRUSH Map A 
容 如 下 : 


# devices 
device © osd.0 


device 1 osd.1 

device 2 osd.2 

device 3 osd.3 

device 4 osd.4 

device 5 osd.5 

device 6 osd.6 

device 7 osd.7 

4 types 

type 0 osd 

type 1 host 

type 2 root 

# buckets 

host ceph-osd-ssd-server-1 { 
id -1 
alg straw 
hash 0 
item osd.0 weight 1.00 
item osd.1 weight 1.00 

} 

host ceph-osd-ssd-server-2 { 
id -2 
alg straw 
hash 0 


item osd.2 weight 1.00 
item osd.3 weight 1.00 


j 

host ceph-osd-platter-server-1 { 
id -3 
alg straw 
hash 0 


item osd.4 weight 1.00 
item osd.5 weight 1.00 


host ceph-osd-platter-server-2 ( 
id -4 


alg straw 

hash 0 

item osd.6 weight 1.00 
item osd.7 weight 1.00 


} 

root platter { 
id -5 
alg straw 
hash 0 


item ceph-osd-platter-server-1 weight 2.00 
item ceph-osd-platter-server-2 weight 2.00 


} 

root ssd { 
id -6 
alg straw 
hash 0 


item ceph-osd-ssd-server-1 weight 2.00 
item ceph-osd-ssd-server-2 weight 2.00 


# rules 
rule replicated ruleset ( 
ruleset 0 
type replicated 
min size 1 
max size 10 
step take default 
step chooseleaf firstn O type host 
step emit 


rule platter { 
ruleset 1 
type replicated 
min_size 0 
max_size 10 
step take platter 
step chooseleaf firstn O type host 


step emit 


rule ssd ( 
ruleset 2 
type replicated 
min size 0 
max size 4 
step take ssd 
step chooseleaf firstn O type host 
step emit 


rule ssd-primary ( 
ruleset 3 
type replicated 
min size 5 
max size 10 
step take ssd 
step chooseleaf firstn 1 type host 
step emit 
step take platter 
step chooseleaf firstn -1 type host 
step emit 


然后 你 可 以 设置 一 个 存储 池 ， 让 它 使 用 SSD 规则 : 


ceph osd pool set «poolname» crush ruleset 2 


同样 ， 用 ssd-primary 规则 将 使 存储 池内 的 各 归 置 组 用 SSD TE OSD » #38 
Be VE S| Ko 


10. 修改 MON IP 


Ceph 客户 端 和 其 他 Ceph 守护 进程 通过 ceph.conf 来 发 现 monitor。 但 是 
monitor 之 间 是 通过 mon map 而 非 ceph.conf 来 发 现 彼此 。 


10.1 修改 MON IP (正确 的 方法 ) 


仅 修改 ceoh.conf 中 mon 的 IP 是 不 足以 确保 集群 中 的 其 他 monitor 收 到 更 新 
的 。 要 修改 一 个 mon 的 IP， 你 必须 先 新 增 一 个 使 用 新 IP. 的 monitor (参考 1.6 增 
加 /删除 Monitor) ， 确 保 这 个 新 mon 成 功 加 入 集群 并 形成 法 定 人 数 。 然 后 ， 删 除 使 
Hw IP 的 mon。 最 后 ， 更 新 ceph.conf ， 以 便 客户 端 和 其 他 守护 进程 可 以 知道 
新 mon 的 IP。 


比如 ， 假 设 现 有 3 个 monitors : 


[mon.a] 

host = host01 

addr = 10.0.0.1:6789 
[mon.b] 

host = host02 

addr = 10.0.0.2:6789 
[mon.c] 


host = host03 
addr = 10.0.0.3:6789 


把 mon.c 变更 为 mon.d 。 按 照 本 手册 第 一 部 分 6. 增加 /删除 Monitor > 34 A0e— 
个 mon.d ，host 设 为 hosto4 > IP 地 址 设 为 10.0.0.4 。 先 司 动 mon.d ^ 
再 按照 6. 增加 /删除 Monitor 删除 mon.c ， 和 否则 会 破坏 法 定 人 数 。 


10.2 修改 MON IP (不 太 友 好 的 方法 ) 


有 时 ，monitor 需要 迁移 到 一 个 新 的 网 络 中 、 数 据 中 心 的 其 他 位 置 或 另 一 个 数据 中 
心 。 这 时 ， 需 要 为 集群 中 所 有 的 monitors 生成 一 个 新 的 mon map (指定 了 新 的 
MON IP) ， 再 注入 每 一 个 monitor 中 。 


还 以 前 面 的 mon 配置 为 例 。 假 定 想 把 monitor 从 10.0.0.x 网 段 改 为 
10.1.0.x 网 段 ， 这 两 个 网 段 直接 是 不 通 的 。 执 行 下 列 步骤 : 


1、 获 取 mon map。 


ceph mon getmap -o {tmp}/{filename} 


2、 下 面 的 例子 说 明了 monmap $9 A X » 
$ monmaptool --print {tmp}/{filename} 


monmaptool: monmap file {tmp}/{filename} 
epoch 1 

fsid 224e376d-c5fe-4504-96bb -ea6332a19e61 
last_changed 2012-12-17 02:46:41.591248 
created 2012-12-17 02:46:41.591248 

0: 10.0.0.1:6789/0 mon.a 

1: 10.0.0.2:6789/0 mon.b 

2: 10.0.0.3:6789/0 mon.c 


3、 删 除 已 有 的 monitors ° 
$ monmaptool --rm a --rm b --rm c {tmp}/{filename} 


monmaptool: monmap file {tmp}/{filename} 

monmaptool: removing a 

monmaptool: removing b 

monmaptool: removing c 

monmaptool: writing epoch 1 to {tmp}/{filename} (0 monitors) 


4 ` #128 monitor ° 


$ monmaptool --add a 10.1.0.1:6789 --add b 10.1.0.2:6789 --add c 
10.1.0.3:6789 {tmp}/{filename} 


monmaptool: monmap file {tmp}/{filename} 
monmaptool: writing epoch 1 to {tmp}/{filename} (3 monitors) 


5^ #4 monmap 的 新 内 容 。 
$ monmaptool --print {tmp}/{filename} 


monmaptool: monmap file {tmp}/{filename} 
epoch 1 

fsid 224e376d-c5fe-4504-96bb -ea6332a19e61 
last_changed 2012-12-17 02:46:41.591248 
created 2012-12-17 02:46:41.591248 

0: 10.1.0.1:6789/0 mon.a 

1: 10.1.0.2:6789/0 mon.b 

2: 10.1.0.3:6789/0 mon.c 


此 时 ， 我 们 假定 monitor 已 在 新 位 置 安 装 完毕 。 下 面 的 步骤 就 是 分 发 新 的 monmap 
并 注入 到 各 新 monitor 中 。 


1、 停 止 所 有 的 monitor 。 必 须 停 止 mon 守护 进程 才能 进行 monmap ÈA ° 


2、 注 入 monmap ° 


ceph-mon -i {mon-id} --inject-monmap {tmp}/{filename} 


3、 重 启 各 monitors ° 


11. 修改 集群 配置 


启动 Ceph 存储 集群 时 ， 各 守护 进程 都 从 同一 个 配置 文件 ( 即 默认 的 ceph.conf 
) 里 查找 它 自己 的 配置 。 ceph.conf 中 可 配置 参数 很 多 ， 有 时 我 们 需要 根据 实际 
环境 对 某 些 参数 进行 修改 。 


修改 的 方式 分 为 两 种 : 直接 修改 sent conf 配置 文件 中 的 参数 值 ， 修 改 完 后 需 
要 重启 Ceph 进程 才能 生效 。 或 在 运行 中 动态 地 进行 参数 调整 ， 无 需 重 局 进程 。 


11.1 查看 运行 时 配置 


如 果 你 的 Ceph 存储 集群 在 运行 ， 而 你 想 看 一 个 在 运行 进程 的 配置 ， 用 下 面 的 命 


a: 


ceph daemon {daemon-type}.{id} config show | less 


果 你 现在 位 于 osd.0 所 在 的 主机 ， 命 令 将 是 


ceph daemon osd.O config show | less 


11.2 修改 配置 文件 

ae 配置 文件 可 用 于 配置 存储 集群 内 的 所 有 守护 进程 、 或 者 某 一 类 型 的 所 有 守护 
进程 。 要 配置 一 系列 守护 进程 ， 这 些 配 置 必 须 位 于 能 收 到 配置 的 段落 之 下 ， 比 如 : 
[global] 


描述 : [global] 下 的 配置 影响 Ceph 集群 里 的 所 有 守护 进程 。 
实例 : auth supported = cephx 


[osd] 


描述 : [osd] TURE i ae ceph-osd 进程 ， 并 且 会 覆盖 
[global] 下 的 同一 选项 。 
实例 : osd journal size = 1000 


[mon] 


描述 : [mon] REN ee a ceph-mon #42° #HARS 
[global] 下 的 同一 选项 。 
实例 : mon addr = 10.0.0.101:6789 


[mds] 


描述 : [mds] TOROS SITUADA ceph-mds 3t4£ » j HE 2X 
[global] 下 的 同一 选项 。 
实例 : host = myserver01 


[client] 


描述 : [client] 下 的 配置 影响 所 有 客户 端 〈 如 挂 载 的 Ceph 文件 系统 、 挂 载 的 
AE ue ) 


块 设备 等 等 
实例 : log file = /var/log/ceph/radosgw. log 


o 


全 局 设置 影响 集群 内 所 有 守护 进程 的 例 程 ， 所 以 [global] 可 用 于 设置 适用 所 有 
守护 进程 的 选项 。 但 可 以 用 这 些 和 覆盖 [global] 设置 : 


1. 在 [osd] ^ [mon] ^ [mds] 下 更 改 某 一 类 进程 的 配置 
2. 更 改 特定 进程 的 设置 ， 如 [osd.1] ° 
会 


覆盖 全 局 设置 会 影响 所 有 子 进程 ， 明 确 别 除 的 例外 。 


11.3 运行 中 动态 调整 


Fa 可 以 在 运行 时 更 改 ceph-osd ^ ceph-mon ^ ceph-mds 守护 进程 的 配 
， 此 功能 在 增加 /降低 日 志 输 出 、 启 用 /禁用 调试 设置 、 其 至 是 运行 时 优化 的 时 候 
Lr 党 有 用 。Ceph 集群 提供 me AO AM ， 使 用 tell 的 方式 和 daemon 设置 

的 方式 。 


tell 方式 设置 
下 面 是 使 用 tell 命令 的 修改 方法 : 


ceph tell {daemon-type}.{id or *} injectargs --{name} {value} [- 
-{name} {value} ] 


用 osd ^ mon `œ mds 中 的 一 个 替代 {daemon-type} ， 你 可 以 用 星 号 
> ) 更 改 一 类 进程 的 所 有 实例 配置 、 或 者 更 改 某 一 具体 进程 ID oA 
F) 的 配置 。 例 如 提高 名 为 osd.0 的 ceph-osd 进程 之 调试 级 别 的 命令 如 


ceph tell osd.0 injectargs --debug-osd 20 --debug-ms 1 
在 ceph.conf 文件 里 配置 时 用 空格 分 隔 关键 词 ; 但 在 命令 行使 用 的 时 候 要 用 下 
划 线 或 连 字 符 ( X - ) 分 隔 ， 例 如 debug osd 变 成 debug-osd ° 
daemon 方式 设置 
除了 上 面 的 tell 的 方式 调整 ， 还 可 以 使 用 daemon 的 方式 进行 设置 。 
1、 获 取 当 前 的 参数 

ceph daemon osd.1 config get mon osd full ratio 


£ 


"mon_osd_full_ratio": "0.98" 


ceph daemon osd.1 config set mon_osd_full_ratio 0.97 


{ 


"success": "mon osd full ratio = '0.97' " 


ceph daemon osd.1 config get mon osd full ratio 


( 


"mon osd full ratio": "9.97" 


j 


注意 : 重启 进程 后 配置 会 恢复 到 默认 参数 ， 在 进行 在 线 调整 后 ， 如 果 这 个 参数 是 后 
续 是 需要 使 用 的 ， 那 么 就 需要 将 相关 的 参数 写 入 到 配置 文件 ceph.conf 当中 。 


两 种 设置 方式 的 使 用 场景 


使 用 tell 的 方式 适合 对 整个 集群 进行 设置 ， 使 用 * 号 进行 匹配 ， 就 可 以 对 整个 集 
群 的 角色 进行 设置 。 而 出 现 节点 异常 无 法 设置 时 候 ， 只 会 在 命令 行当 中 进行 报错 ， 
不 太 便 于 查找 。 


使 用 daemon 进行 设置 的 方式 就 是 一 个 个 的 去 设置 ， 这 样 可 以 比较 好 的 反馈 ， 此 方 
法 是 需要 在 设置 的 角色 所 在 的 主机 上 进行 设置 。 


12. 日 志和 调试 


一 般 来 说 ， 你 应 该 在 运行 时 增加 调试 选项 来 调试 问题 ; 也 可 以 把 调试 选项 添加 到 
Ceph 配置 文件 里 来 调试 集群 启动 时 的 问题 ， 然 后 查看 /var/log/ceph (Rite 
置 ) 下 的 日 志文 件 。 

Tip: 调试 输出 会 拖 慢 系统 ， 这 种 延 时 有 可 能 掩盖 竞争 条 件 。 


日 志 记 录 是 资源 密集 型 任务 。 如 果 你 碰 到 的 问题 在 集群 的 某 个 特定 区 域 ， 只 启用 那 
个 区 域 对 应 的 日 志 功 能 即 可 。 例 如 ， 你 的 OSD 运行 良好 、 元 数据 服务 器 却 有 问 
题 ， 这 时 应 该 先 打开 那个 可 疑 元 数据 服务 器 实例 的 调试 日 志 ; 如 果 不 行 再 打开 各 子 
系统 的 日 志 。 


重要 : 详尽 的 日 志 每 小 时 可 能 超过 1GB ， 如 果 你 的 系统 盘 满 了 ， 这 个 节点 就 会 售 
JE IAE © 


如 果 你 要 打开 或 增加 Ceph 日 志 级 别 ， 确 保有 足够 的 系统 盘 空 间 。 滚 动 日 志文 件 的 
方法 见 下 面 的 mkA SER 小 节 。 集 群 稳定 运行 后 ， 可 以 关闭 不 必要 的 调试 选项 
以 优化 运行 。 集 群 在 运行 中 记录 调试 输出 信息 会 拖 慢 系 统 、 且 浪费 资源 。 


ceph daemon {daemon-name} config show | less 


例如 : 


ceph daemon osd.0 config show | less 


要 在 运行 时 激活 Ceph 的 调试 输出 (BP dout() ) ， 用 ceph tell 命令 把 参数 
注入 运行 时 配置 : 


ceph tell {daemon-type}.{daemon id or *} injectargs --{name} {va 
lue) [--{name} {value}] 


用 osd mon 3 mds 替代 
置 应 用 到 同类 型 的 所 有 守护 进 
ods.0 的 ceph-osd 守护 


N 


9 


T 
dtf 
ceph tell osd.0O injectargs 


ceph tell 命令 会 通过 monitor 
你 要 改 的 那 台 主 机 然后 用 ceph da 


sudo ceph daemon osd.O con 


12.2 司 动 时 
要 在 启动 时 激活 调试 输出 (FP do 
有 配置 可 写 在 配置 文件 的 
程 段 下 (如 [mon] ^ [osd] 
[global] 
debug ms = 1/5 
[mon ] 
debug mon = 20 
debug paxos = 1/5 
debug auth = 
[osd] 
debug osd = 1/5 
debug filestore = 
debug journal = 
debug monc = 5/20 
[mds ] 
debug mds = 1 
debug mds balancer 
debug mds log = 
debug mds migrator 


docu doom o ATRAZ ( * ) 把 配 
或 者 指定 具体 守护 进程 的 ID 。 例 如 ， 要 给 名 为 
星 提 高 调试 级 别 ， 用 下 列 命令 


--debug-osd 0/5 


起 作用 。 如 果 你 不 能 绑 定 monitor， 仍 可 以 登录 
emon 来 更 改 。 例 如 : 


fig set debug osd 0/5 


ut() ) ， 你 得 把 选项 加 入 配置 文件 。 各 进程 共 


[global] 段 下 ， 某 类 进程 的 配置 可 写 在 对 应 的 守护 进 


N 


[mds] ) ° Bite: 


1/5 


12.3 加 快 日 志 


你 的 系统 盘 比 较 满 ， 可 以 修改 /etc/logrotate.d/ceph ANA SRARE 
， OR ETIN 去 size 选项 (达到 此 大 小 就 滚动 ) 来 加 
快 滚动 (通过 cronjob ) 。 例 如 默认 配置 大 致 如 此 : 


rotate 7 
weekly 
compress 
sharedscripts 


增加 一 个 size 选项。 


rotate 7 
weekly 

size 500M 
compress 
sharedscripts 


2, 


Æ * 477 crontab 编辑 器 


o 


crontab -e 


最 后 ， 增 加 一 条 用 以 检查 /etc/logrorate.d/ceph TAHE © 


30* * * * /usr/sbin/logrotate /etc/logrotate.d/ceph >/dev/null 
2>&1 


本 例 中 每 30 分 钟 检 查 一 次 /etc/logrorate.d/ceph 文件 。 


12.4 VALGRIND 工具 


调试 时 可 能 还 需要 追踪 内 存 和 线程 问题 。 你 可 以 在 Valgrind 中 运行 单个 守护 进程 、 
一 类 进程 、 或 整个 集群 Valgrind 是 计算 密集 型 程序 ， 应 该 只 用 于 开发 或 调试 
Ceph， 否 则 它 会 拖 慢 系统 。Valgrind 的 消息 会 记录 到 stderr ° 


12.5 子 系统 、 日 志和 调试 选项 


大 多 数 情况 下 ， 你 可 以 通过 子 系统 打开 调试 日 志和 输出。 


CEPH 子 系统 概览 


各 子 系统 都 有 日 志 级 别 用 于 分 别 控制 其 输出 日 志和 暂 存 日 志 《〈 内 存 中 ) ， 你 可 以 分 
别 为 ee 。 Ceph 的 日 志 级 别 从 1 到 20 ，1 是 简洁 、 
20 是 详尽 。 ， 内 存 驻 留 日 志 不 会 发 送 到 输出 日 志 ， 除 非 : 


e 致命 信号 出 现 ， 或 者 
e 源码 中 的 assert 被 触发 ， 或 者 
e 明确 要 求 发 送 。 


调试 选项 允许 用 单个 数字 同时 设置 日 志 级 别 和 内 存 级 别 ， 这 会 将 二 者 设置 为 一 样 的 
值 。 比 如 ， 如 果 你 指定 debug ms = 5 ，Ceph 会 把 日 志 级 别 和 内 存 级 别 都 设置 
A 5 。 也 可 以 分 别 设置 ， 第 一 个 选项 是 日 志 级 别 、 第 二 个 是 内 存 级 别 ， 二 者 必须 
AR (CI) 分 隔 。 假 如 你 想 把 ms 子 系统 的 调试 日 志 级 别 设 为 1 、 内 存 级 别 
mA 5 ， 可 以 写 为 debug ms = 1/5 ， 如 下 : 


debug {subsystem} = {log-level}/{memory-level} 
#for example 
debug mds log = 1/20 


Ceph 子 系统 及 其 默认 日 志和 内 存 级 别 具 体 见 SUBSYSTEM, LOG AND DEBUG 
SETTINGS 。 一 旦 你 完成 调试 ， 应 该 恢复 默认 值 ， 或 一 个 适合 平常 运营 的 级 别 。 
日 志 记 录 选 项 


关于 日 志 记 录 选 项 的 详细 信息 ， 可 以 参考 Ceph 官方 文档 的 对 应 内 容 LOGGING 
SETTING ° 


第 二 部 分 : 故障 处 理 


本 部 分 就 Ceph 存储 集群 常见 的 问题 做 了 归纳 和 总 结 ， 方 便 运 维 人 员 进 行 故障 排 


ER o 


1. 第 见 MON 故障 处 理 


Monitor 维护 着 Ceph 集群 的 信息 ， 如 果 Monitor 无 法 正常 提供 服务 ， 那 整个 Ceph 
集群 就 不 可 访问 。 一 般 来 说 ， 在 实际 运行 中 ，Ceph Monitor 的 个 数 是 2n+ 1(n >= 
0) 个 ， 在 线 上 至 少 3 个 ， 只 要 正常 的 节点 数 >= n+1，Ceph 的 Paxos HAR AE RTE 
系统 的 正常 运行 。 所 以 ， 当 Monitor 出 现 故障 的 时 候 ， 不 要 惊 懂 ， 冷 静 下 来 ， 一 步 
一 步 地 处 理 。 


1.1 开始 排 障 

在 遭遇 Monitor 故障 时 ， 首 先 回答 下 列 几 个 问题 : 

Mon 进程 在 运行 吗 ? 

我 们 首先 要 确保 Mon 进程 是 在 正常 运行 的 。 很 多 人 往往 忽略 了 这 一 点 。 
是 否 可 以 连接 Mon Server ? 


有 时 候 我 们 开启 了 防火 墙 ， 导 致 无 法 与 Monitor 的 IP 或 端口 进行 通信 。 尝 试 使 用 
ssh 连接 服务 器 ， 如 果 成 功 ， 再 尝试 用 其 他 工具 (如 telnet > nc +) & 

接 monitor 的 端口 。 

ceph -s 命令 是 否 能 运行 并 收 到 集群 回复 ? 

如 果 答 案 是 肯定 的 ， 那 么 你 的 集群 已 启动 并 运行 着 。 你 可 以 认为 如 果 已 经 形成 法 定 


人 数 ，monitors 就 只 会 响应 status 请 求 。 


an ceph -s 阻塞 了 ， 并 没有 收 到 集群 的 响应 且 输 出 了 很 多 fault 信息 ， 很 
能 此 时 你 的 monitors 全 部 都 down 掉 了 或 只 有 部 分 在 运行 (但 数量 不 足以 形成 法 
Men o 


ceph -s 没完 成 是 什么 情况 ? 
如 果 你 到 目前 为 止 没有 完成 前 述 的 几 步 ， 请 返回 去 完成 。 然 后 你 需要 ssh 登录 到 
务 器 上 并 使 用 monitor 的 管理 套 接 字 。 


1.2 使 用 Mon 的 管理 套 接 字 


通过 管理 套 接 字 ， 你 可 以 用 Unix 套 接 字 文件 直接 与 指定 守护 进程 交互 。 这 个 文件 
位 于 你 Mon 节点 的 run 目录 下 ， 默 认 配 置 它 位 于 /var/run/ceph/ceph- 
mon.ID.asok ， 但 要 是 改过 配置 就 不 一 定 在 那里 了 。 如 果 你 在 那里 没 找到 它 ， 请 
检查 ceph.conf 里 是 否 配置 了 其 它 路 径 ， 或 者 用 下 面 的 命令 获取 : 


ceph-conf --name mon.ID --show-config-value admin socket 


请 牢记 ， 只 有 在 Mon 运行 时 管理 套 接 字 才 可 用 。Mon 正常 关闭 时 ， 管 理 套 接 字 会 

被 删除 ; 如 果 Mon 不 运行 了 、 但 管理 套 接 字 还 存在 ， 就 说 明 Mon 不 是 正常 关闭 

的 。 不 管 怎样 ，Mon 没 在 运行 ， 你 就 不 能 使 用 管理 套 接 字 ， cep 命令 会 返回 类 
似 Error 111: Connection Refused 的 错误 消息 。 

访问 管理 套 接 字 很 简单 ， 就 是 让 ceph 工具 使 用 asok 文件 。 对 于 Dumpling 之 
前 的 版 本 ， 命 令 是 这 样 的 : 


ceph --admin-daemon /var/run/ceph/ceph-mon.«id».asok «command» 


对 于 Dumpling 及 后 续 版 本 ， 你 可 以 用 另 一 个 〈 推 荐 的 ) 命令 : 


ceph daemon mon.«id» «command» 


ceph 工具 的 help 命令 会 显示 管理 套 接 字 支 持 的 其 它 命 令 。 请 仔细 了 解 一 下 


config get ^ config show ^ mon status 和 quorum status 命令 ， 


在 排除 Mon 故障 时 它们 会 很 有 用 。 


1.3 理解 MON. STATUS 


当 集 群 形 成 法 定 人 数 后 ， 或 在 没有 形成 法 定 人 数 时 通过 管理 套 接 字 ， 用 ceph 工 
具 可 以 获得 mon status 信息 。 命 令 会 输出 关于 monitor 的 大 多 数 信 息 ， 包 括 部 


分 quorum status 命令 的 输出 内 容 。 


T€ mon status 的 输出 样 例 : 


"name" : Mosis 
"rank": 2, 
"state": "peon", 


"election epoch": 38, 
"quorum": [ 


1, 
2 
], 
"outside quorum": [], 
"extra probe peers": [], 
"sync provider": [], 
"monmap": ( 
"epoch": 3, 
"fsid": "5c4e9d53-e2e1-478a-8061-f543f8be4cf8", 
"modified": "2013-10-30 04:12:01.945629", 
"created": "2013-10-29 14:14:41.914786", 
"mons": [ 
{ 
"rank": 0, 
"name": "a", 
"addr": "127.0.0.1:6789\/0" 
ty 
{ 
"rank": 1, 
"name": "p", 
"addr": "127.0.0.1:6790\/0" 
ty 
{ 
"rank": 2, 
"name": “c", 
"addr": "127.0.0.1:6795\/0" 
} 
] 
} 


从 上 面 的 信息 可 以 看 出 ，monmap ¥ & 4 3 个 monitor (abf c) ， 只 有 2 个 
monitor 形成 了 法 定 人 数 ，c 是 法 定 人 数 中 的 peon 角色 (FE leader 角色 ) 。 


还 可 以 看 出 ，a 并 不 在 法 定 人 数 之 中 。 请 看 quorum 集合 。 在 集合 中 只 有 T 和 2 
。 这 不 是 monitor 的 名 字 ， 而 是 monmap 后 确定 的 等 级 。 丢 失 了 等 级 
0 的 monitor， 根 据 monmap ， 这 个 monitor 就 是 mon.a ° 


那么 ，monitor 的 等 级 是 如 何 确定 的 ? 


当 加 入 或 删除 monitor 时 ， 会 (重新) 计算 等 级 。 计 算 时 遵循 一 个 简单 的 规则 : 
IP:PORT 的 组 合 值 越 大 ， es (等 级 数字 越 大 ， 级 别 越 低 ) 。 因 此 在 上 例 
P> 127.0.0.1:6789 比 其 他 IP:PORT 的 组 合 值 都 小 ， 所 以 mon.a 的 等 级 
是 0。 


1.4 到 常见 的 Mon 问题 


达到 了 法 定 人 数 但 是 有 至 少 一 个 Monitor 处 于 Down KA 


当 此 种 情况 发 生 时 ， 根 据 你 运行 的 Ceph 版 本 ， 可 能 看 到 类 似 下 面 的 输出 : 


root@OPS-ceph1:~# ceph health detail 
HEALTH WARN 1 mons down, quorum 1,2 b,c 
mon.a (rank ©) addr 127.0.0.1:6789/0 is down (out of quorum) 


如 何 解 决 ? 
首先 ， 确 认 mon.a 进程 是 否 运行 


其 次 ， 确 定 可 以 从 其 他 monitor 节点 连 到 mon.a 所 在 节点 。 同 时 检查 下 端口 。 如 
X31 防火 墙 ， 还 需要 检查 下 所 有 monitor 节点 的 iptables ， 以 确定 没有 丢弃 / 
拒绝 连接 。 


如 果 前 两 步 没有 解决 问题 ， 请 继续 往 下 走 。 


首先 ， 通 过 管理 套 接 字 检查 问题 monitor 的 mon status 。 考 虑 到 该 monitor 并 
不 在 法 定 人 数 中 ， 它 的 状态 应 该 是 probing ， electing 或 

synchronizing 中 的 一 种 。 如 果 它 恰巧 是 leader 或 peon 角色 ， 它 会 认为 
自己 在 法 定 人 数 中 ， 但 集群 中 其 他 monitor 并 不 这 样 认为 。 或 者 在 我 们 处 理 故 障 的 
过 程 中 它 加 入 了 法 定 人 数 ， 所 以 再 次 使 用 ceph -s 确认 下 集群 状态 。 如 果 该 
monitor 还 没 加 入 法 定 人 数 ， 继 续 。 


probing 状态 是 什么 情况 ? 


这 意味 着 该 monitor 还 在 搜寻 其 他 monitors 。 每 次 你 启动 一 个 monitor， 它 会 去 搜 

+ monmap 中 的 其 他 monitors ， 所 以 会 有 一 段 时 间 处 于 该 状态 。 此 段 时 间 的 长 短 
不 一 。 例 如 ， 单 节点 monitor 环境 ，monitor 几乎 会 立即 通过 该 阶段 。 在 多 monitor 
环境 中 ，monitors 在 找到 足够 的 节点 形成 法 定 人 数 之 前 ， 都 会 处 于 该 状态 ， 这 意味 
着 如 果 3 monitor 中 的 2 个 down 了 ， 剩 下 的 1 个 会 一 直 处 于 该 状态 ， 直 到 你 再 
启动 一 个 monitor ° 


如 果 你 的 环境 已 经 形成 法 定 人 数 ， 只 要 monitor 之 间 可 以 互通 ， 新 monitor 应 该 可 
以 很 快 搜寻 到 其 他 monitors 。 如 果 卡 在 probing 状态 ， 并 且 排 除了 连接 的 问题 ， 那 
很 有 可 能 是 该 monitor 在 尝试 连接 一 个 错误 的 monitor 地 址 。 可 以 根据 

mon status 命令 输出 中 的 monmap 内 容 ， 检 查 其 他 monitor 的 地 址 是 否 和 实际 
相符 。 如 果 不 相 符 ， 请 跳 至 恢复 Monitor 损坏 的 monmap。 如 果 相 符 ， 这 些 
monitor 节点 问 可 能 存在 严重 的 时 钟 偏 移 问 题 ， 请 首先 参考 时 钟 偏 移 ， 如 果 没 有 解 
决 问题 ， 可 以 搜集 相关 的 日 志 并 向 社区 求助 。 


electing 状态 是 什么 情况 ? 


这 意味 着 该 monitor 处 于 选举 过 程 中 。 选 举 应 该 很 快 就 可 以 完成 ， 但 偶尔 也 会 卡 
住 ， 这 往往 是 monitors 节点 时 钟 偏 移 的 一 个 标志 ， 跳 转 至 时 钟 偏 移 获取 更 多 信息 。 
如 果 时 钟 是 正确 同步 的 ， 可 以 搜集 相关 日 志 并 向 社区 求助 。 此 种 情况 除非 是 一 些 
(非常 ) 古老 的 bug， 往 往 都 是 由 时 钟 不 同步 引起 的 。 
synchronizing 状态 是 什么 情况 ? 


这 意味 着 该 monitor 正在 和 集群 中 的 其 他 monitor 进行 同步 以 便 加 入 法 定 人 数 。 
Monitor 的 数据 库 越 小 ， 同 步 过程 的 耗 时 就 越 短 。 


然而 ， 如 果 你 注意 到 monitor 的 状态 从 synchronizing 变 为 electing 后 又 变 回 
synchronizing ， 那 么 就 有 问题 了 : 集群 的 状态 更 新 的 太 快 〈 即 产生 新 的 maps ) ， 
同步 过 程 已 经 无 法 追赶 上 了 。 这 种 情况 在 早期 版 本 中 可 以 见 到 ， 但 现在 经 过 代码 重 
构 和 增强 ， 在 较 新 版 本 中 已 经 基本 见 不 到 了 。 


leader 或 peon 状态 是 什么 情况 ? 

这 种 情况 不 应 该 发 生 ， 但 还 是 有 一 定 概率 会 发 生 ， 这 常 和 时 钟 偏 移 有 关 。 如 果 你 并 
没有 时 钟 偏 移 的 问题 ， 请 搜集 相关 的 日 志 并 向 社区 求助 。 

恢复 Monitor 损坏 的 monmap 


monmap 通常 看 起 来 是 下 面 的 样子 ， 这 取决 于 monitor 的 个 数 : 


epoch 3 

fsid 5c4e9d53-e2e1-478a-8061-f543f8be4cf8 
last changed 2013-10-30 04:12:01.945629 
created 2013-10-29 14:14:41.914786 

0: 127.0.0.1:6789/0 mon.a 

1: 127.0.0.1:6790/0 mon.b 

2: 127.0.0.1:6795/0 mon.c 


不 过 也 不 一 定 就 是 这 样 的 内 容 。 比 如 ， 在 早期 版 本 的 Ceph 中 ， 有 一 个 严重 bug 会 
导致 monmap 的 内 容 全 为 0。 这 意味 着 即使 用 monmaptool 也 不 能 读 取 它 ， 
为 全 0 的 内 容 没 有 任何 意义 。 另 外 一 些 情况 ， 某 个 monitor 所 持 有 的 monmap 已 
严重 过 期 ， 以 至 于 无 法 搜寻 到 集群 中 的 其 他 monitors 。 在 这 些 状 况 下 ， 你 有 两 种 可 
行 的 解决 方法 : 

销毁 monitor 然后 新 建 


只 有 在 你 确定 不 会 丢失 保存 在 该 monitor 上 的 数据 时 ， 你 才能 够 采用 这 个 方法 。 也 
就 是 说 ， 集 群 中 还 有 其 他 运行 正常 的 monitors ， 以 便 新 monitor 可 以 和 其 他 
monitors 达到 同步 。 请 说 记 ， 销 毁 一 个 monitor 时 ， 如 果 没 有 其 上 数据 的 备份 ， 可 
能 会 丢失 数据 。 


给 monitor 手动 注入 monmap 


通常 是 最 安全 的 做 法 。 你 应 该 从 剩余 的 monitor 中 抓 取 monmap， 然 后 手动 注入 
monmap 有 问题 的 monitor 节点 。 


下 面 是 基本 步骤 : 


1、 是 否 已 形成 法 定 人 数 ? 如 果 是 ， 从 法 定 人 数 中 抓 取 monmap : 


ceph mon getmap -o /tmp/monmap 


2、 没 有 形成 法 定 人 数 ? 直接 从 其 他 monitor 节点 上 抓 取 monmap 《这 里 假定 你 抓 
取 monmap 的 monitor & id 是 ID-FOO 并 且 守 护 进程 已 经 停止 运行 ) 


ceph-mon -i ID-FOO --extract-monmap /tmp/monmap 


3、 停 止 你 想 要 往 其 中 注入 monmap 的 monitor 。 


4 ^ i£ monmap ° 
ceph-mon -i ID --inject-monmap /tmp/monmap 


5 * È 3l monitor ° 


请 记 住 ， 能 够 注入 monmap 是 一 个 很 强大 的 特性 ， 如 果 滥 用 可 能 会 对 monitor 造成 
大 破坏 ， 因 为 这 样 做 会 覆盖 monitor 持 有 的 最 新 monmap 。 


时 钟 偏 移 


Monitor 节点 间 明 显 的 时 钟 偏 移 会 对 monitor 造成 严重 的 影响 。 这 通常 会 导致 一 些 
奇怪 的 问题 。 为 了 避免 这 些 问题 ， 在 monitor 节点 上 应 该 运行 时 间 同 2 


4 
H 
m 


允许 的 最 大 时 钟 偏 移 量 是 多 少 ? 
默认 最 大 允许 的 时 钟 偏 移 量 是 g.05 f^ 。 
如 何 增加 最 大 时 钟 偏 移 量 ? 


通过 mon-clock-drift-allowed 选项 来 配置 。 尽 管 你 可 以 修改 但 不 代表 你 应 该 修 
7X 0 时 钟 偏 移 机 制 之 所 以 是 合理 的 , ay eae 的 monitor 可 能 会 表现 不 正 

常 o 未 经 测 | 试 而 修改 该 值 , 尽管 没有 丢失 数据 的 风险 但 仍 可 能 会 对 "—— 的 稳 
定性 和 集群 的 健康 造成 不 可 预知 的 影响 。 


如 何 知道 是 否 存 在 时 钟 偏 移 ? 
Monitor 会 用 HEALTH WARN 的 方式 警告 你 。 ceph health detail 应 该 输出 如 


下 格式 的 信息 : 


mon.c addr 10.10.0.1:6789/0 clock skew 0.08235s > max 0.05s (lat 
ency 0.0045s) 


这 表示 mon.c 已 被 标记 出 正在 遭受 时 钟 偏 移 。 


如 果 存 在 时 钟 偏 移 该 怎么 处 理 ? 


服务 ， 但 仍 遭 遇 此 问题 ， 检 查 一 下 使 用 的 NTP 服务 器 是 否 离 你 的 网 络 太 过 志和 远 ， 


同步 各 monitor 节点 的 时 钟 。 运 行 NTP 客户 端 会 有 帮助 。 如 果 你 已 经 启动 了 NTP 
然后 可 以 考虑 在 你 的 网 络 环境 中 运行 自己 的 NTP 服务 器 。 最 后 这 种 选择 可 趋 于 减 


'Y monitor 时 钟 偏 移 带 来 的 问题 。 


端 无 法 连接 或 挂 载 


检查 IP 过 滤 表 。 某 些 操作 系统 安装 工具 会 给 iptables 增加 一 条 REJECT 规 
则 。 这 条 规则 会 拒绝 所 有 尝试 连接 该 主机 的 客户 端 〈 除 了 ssh ) 。 如 果 你 的 


monitor 主机 设置 了 这 条 防火 墙 REJECT 规则 ， 客 户 端 从 其 他 节点 连接 过 来 时 就 
会 超时 失败 。 你 需要 定位 出 拒绝 客户 端 连接 守护 进程 的 那 条 iptables 规 
则 。 比 如 ， 你 需要 对 类 似 于 下 面 的 这 条 规则 进行 适当 处 理 : 


REJECT all -- anywhere anywhere reject-with icmp-host-prohibited 


尔 还 需要 给 Ceph 主机 的 IP 过 滤 表 增加 规则 ， 以 确保 客户 端 可 以 访问 Ceph 
monitor (默认 端口 6789 ) 和 Ceph OSD (ZRU 6800 ~ 7300 ) 的 相关 端口 。 


iptables -A INPUT -m multiport -p tcp -s {ip-address}/{netmask} 
--dports 6789,6800:7300 -j ACCEPT 


或 者 ， 如 果 你 的 环境 允许 ， 也 可 以 直接 关闭 主机 的 防火 墙 。 


1.5 Monitor 数据 库 失 败 


BK VE JE AA Tit AY Fe 


Ceph monitor 把 集群 的 各 种 map 信息 存放 在 key/value 数据 库 中 ， 如 LevelDB ° 
如 果 monitor 是 因为 数据 库 崩 溃 而 失败 ， 在 monitor 的 log 日 志 中 应 该 会 有 如 下 错 


误 信 息 : 


Corruption: error in middle of record 


或 : 
或 : 


Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store 
.db/1234567.1db 


通过 健康 的 Monitor(s) 恢复 


如 果 还 有 幸存 的 monitor， 我 们 通常 可 以 用 新 的 数据 库 替 换 谣 溃 的 数据 库 。 并 且 在 
启动 后 ， 新 加 入 的 成 员 会 和 其 他 健康 的 伙伴 进行 同步 ， 一 旦 同步 完成 ， 它 就 可 以 为 
客户 端 提供 服务 了 。 


通过 OSDs 恢复 


但 是 万 一 所 有 的 monitors 都 同时 失败 了 该 怎么 办 ?3 由 于 建议 用 户 在 部 署 集群 时 至 少 
安装 3 个 monitors， 同 时 失效 的 可 能 性 较 小 。 但 是 数据 中 心意 外 的 断 电 ， 再 加 上 磁 
盘 / 文 件 系 统 配 置 不 当 ， 可 能 会 引起 底层 文件 系统 失败 ， 从 而 杀 掉 所 有 的 monitors 

。 这 种 情况 下 ， 我 们 可 以 通过 存放 在 OSDs 上 的 信息 来 恢复 monitor 的 数据 库 : 


ms-/tmp/mon-store 
mkdir $ms 
# collect the cluster map from OSDs 
for host in $hosts; do 
rsync -avz $ms user@host:$ms 
rm -rf $ms 
ssh user@host ««EOF 
for osd in /var/lib/osd/osd-*; do 
ceph-objectstore-tool --data-path $osd --op update 
-mon-db --mon-store-path $ms 
done 
EOF 
rsync -avz user@host:$ms $ms 
done 
# rebuild the monitor store from the collected map, if the clust 
er does not 
# use cephx authentication, we can skip the following steps to u 
pdate the 
# keyring with the caps, and there is no need to pass the "--key 
ring" option. 
# i.e. just use "ceph-monstore-tool /tmp/mon-store rebuild" inst 
ead 
ceph-authtool /path/to/admin.keyring -n mon. \ 
--cap mon allow ‘allow *' 
ceph-authtool /path/to/admin.keyring -n client.admin \ 
--cap mon allow ‘allow *' --cap osd ‘allow *' --cap mds ‘allow 
20 
ceph-monstore-tool /tmp/mon-store rebuild -- --keyring /path/to/ 
admin.keyring 
# backup corrupted store.db just in case 
mv /var/lib/ceph/mon/mon.0/store.db /var/lib/ceph/mon/mon.0/stor 
e.db.corrupted 
mv /tmp/mon-store/store.db /var/lib/ceph/mon/mon.0/store.db 


上 面 的 这 些 步骤 : 


1. 从 所 有 的 OSD 主机 上 收集 map 信息 。 
2. 重建 数据 库 。 
3. 用 恢复 副本 替换 mon.0 上 崩溃 的 数据 库 。 


已 知 的 限制 
下 面 这 些 信息 无 法 通过 上 述 步 骤 恢 复 : 


e 一 些 新 增 的 keyring : 通过 ceph auth add 命令 增加 的 所 有 OSD keyrings 
都 可 以 恢复 。 用 ceph-monstore-tool 可 以 导入 client.admin 的 
PM 。 但 是 MDS 和 其 他 keyrings 在 被 恢复 的 那个 monitor 数据 库 中 就 会 
丢失 。 你 可 能 需要 手动 重新 添加 一 下 。 

e zn. ceph pg set full ratio 和 ceph pg 
set nearfull ratio 命令 设置 的 full ratio 和 nearfull ratio 值 
会 丢失 。 

e MDS Maps : MDS maps 会 丢失 。 


me A Jal BSB MON DOWN 
35 monitor 进程 检测 到 本 地 可 用 磁盘 空间 不 足 时 ， 会 停止 monitor IRS » Monitor 的 


日 志 SN 中 应 该 会 有 类 似 如 下 信息 Ww 的 输 ES 


2016-09-01 16:45:54.994488 7fbicac09700 © mon.jyceph01Q0(leader 
).data health(62) update stats avail 5% total 297 GB, used 264 G 
B, avail 18107 MB 

2016-09-01 16:45:54.994747 7fb1cac09700 -1 mon.jyceph01Q0(leader 
).data_health(62) reached critical levels of available space on 
local monitor storage -- shutdown! 


清理 本 地 磁盘 ， 增 大 可 用 空间 ， 重 启 monitor 进程 ， 即 可 恢复 正常 。 


Ait Mon 数据 库 的 备份 恢复 


请 参考 本 手册 第 三 部 分 2. Monitor 的 备份 和 恢复 。 


2. 第 见 OSD 故障 处 理 


进行 OSD 排 障 前 ， 先 检查 一 下 monitors 和 网 络 。 如 果 ceph health 或 ceph 
-s 返回 的 是 健康 状态 ， 这 意味 着 monitors 形成 了 法 定 人 数 。 如 果 monitor 还 没 达 
到 法 定 人 数 、 或 者 monitor 状态 错误 ， 要 先 解 决 monitor 的 问题 。 核 实 下 你 的 网 
络 ， 确 保 它 在 正常 运行 ， 因 为 网 络 对 OSD 的 运行 和 性 能 有 显著 影响 。 


2.1 收集 OSD 数据 


开始 OSD 排 障 的 第 一 步 最 好 先 收集 信息 ， 另 外 还 有 监控 OSD 时 收集 的 ， 如 ceph 
osd tree ° 


Ceph A & 


如 果 你 没 改 默 认 路 径 ， 可 以 在 /var/log/ceph 下 找到 Ceph 的 日 志 : 


ls /var/log/ceph 


果 看 到 的 日 志 还 不 够 详细 ， 可 以 增 大 日 志 级 别 。 请 参考 1.12 日 志和 调试 ， 查 阅 如 
何 保 证 看 到 大 量 日 志 又 不 影响 集群 运行 。 


管理 套 接 字 


管理 套 接 字 工 具 检索 运行 时 信息 。 列 出 节点 上 所 有 Ceph 套 接 字 : 


ls /var/run/ceph 


然后 ， 执 行 下 例 命令 显示 可 用 选项 ， 把 {daemon-name} 换 成 实际 的 守护 进程 
(如 osd.0 ) 


ceph daemon osd.0 help 


或 者 ， 你 也 可 以 指定 一 个 (socket-file) (如 /var/run/ceph 下 的 文件 ) 


ceph daemon {socket-file} help 


和 其 它 手段 相 比 ， 管 理 套 接 字 允 许 你 : 


e 在 运行 时 列 出 配置 
e 列 出 历史 操作 
e 列 出 操作 的 优先 队列 状态 
e 列 出 在 进行 的 操作 
列 出 性 能 计数 器 


显示 可 用 空间 


可 能 会 引起 文件 系统 问题 。 用 df 命令 显示 文件 系统 的 可 用 空间 。 


其 它 用 法 见 df --help 。 


VO 统计 信息 


用 iostat 工具 定位 I/O 相关 问题 。 


iostat -x 


诊断 信息 


要 查看 诊断 信息 ， 配 合 less ^ more ^ grep 或 tail 使 用 dmesg ， 例 


dmesg | grep scsi 


2.2 停止 数据 向 外 重 平衡 


尔 得 周期 性 地 对 集群 的 子 集 进行 维护 ， 或 解决 某 个 故障 域 的 问题 (如 某 个 机 架 ) © 
如 果 你 不 想 在 停机 维护 OSD 时 让 CRUSH 自动 重 均 衡 ， 首 先 设置 集群 的 noout 


标志 : 


ceph osd set noout 


设置 了 noout 后 ， 你 就 可 以 停机 维护 失败 域内 的 OSD T e 


stop ceph-osd id={num} 


注意 : 在 定位 某 故 障 域 内 的 问题 时 ， 停 机 的 OSD 内 的 PG 状态 会 变 为 degraded 


o 


维护 结束 后 ， 重 启 OSD e 


start ceph-osd id={num} 


最 后 ， 解 除 noout 标志 。 


ceph osd unset noout 


2.3 OSD 没 运 行 
通常 情况 下 ， 简 单 地 重启 ceph-osd 进程 就 可 以 让 它 重 回 集群 并 恢复 。 


OSD 起 不 来 
如 果 你 重启 了 集群 ， 但 其 中 一 个 OSD 起 不 来 ， 依 次 检查 : 


e 配置 文件 : 如 果 你 新 装 的 OSD 不 能 启动 ， 检 查 下 配置 文件 ， 确 保 它 符合 规定 
(比如 host 而 非 hostname ， 等 等 ) 。 


e 检查 路 径 : 检查 配置 文件 的 路 径 ， 以 及 OSD 的 数据 和 日 志 分 区 路 径 。 如 果 你 
TAT OSD 的 数据 和 日 志 分 区 、 而 配置 文件 和 实际 挂 载 点 存在 出 入 ， 启 动 
OSD 时 就 可 能 失败 。 如 果 你 想 把 日 志 存 储 于 一 个 块 设备 ， 应 该 为 日 志 硬盘 分 
区 并 为 各 OSD 分 别 指定 一 个 分 区 。 


e 检查 最 大 线程 数 : 如 果 你 的 节点 有 很 多 OSD ， 也 许 就 会 触 碰 到 默认 的 最 大 线 
程 数 限制 (如 通常 是 32k +) ， 尤 其 是 在 恢复 期 间 。 你 可 以 用 sysctl 增 大 
线程 数 ， 把 最 大 线程 数 更 改 为 支持 的 最 大 值 ( 即 4194303 ) ， 看 看 是 否 有 
用 。 例 如 : 


sysctl -w kernel.pid max-4194303 


如 果 增 大 最 大 线程 数 解决 了 这 个 问题 ， 你 可 以 把 此 配置 kernel.pid max 写 入 配 
置 文件 /etc/sysctl.conf ， 使 之 永久 生效 ， 例 如 : 


kernel.pid max = 4194303 


e 内 核 版 本 : 确认 你 使 用 的 内 核 版 本 和 发 布 版 本 。 Ceph 默认 依赖 一 些 第 三 方 工 
具 ， 这 些 工 具 可 能 有 缺陷 或 者 与 特定 发 布 版 和 /或 内 核 版 本 冲突 (如 Google 
perftools ) 。 检 查 下 操作 系统 推荐 表 ， 确 保 你 已 经 解决 了 内 核 相 关 的 问题 。 


e 段 错误 : 如 果 有 了 段 错 误 ， 提 高 日 志 级 别 (如 果 还 没 提高 ) ， 再 试 试 。 如 果 重 
现 了 ， 联 系 ceph-devel 邮件 列表 并 提供 你 的 配置 文件 、monitor 输出 和 日 志文 
件 内 容 。 


OSD 失败 


当 ceph-osd 挂 掉 时 ，monitor 可 通过 活着 的 ceph-osd 了 解 到 此 情况 ， 并 通过 
ceph health 命令 报告 : 


ceph health 
HEALTH_WARN 1/3 in osds are down 


特别 地 ， 有 ceph-osd 进程 标记 为 in E down 的 时 候 ， 你 也 会 得 到 警告 。 你 
可 以 用 下 面 的 命令 得 知 哪个 ceph-osd 进程 挂 了 : 


ceph health detail 

HEALTH WARN 1/3 in osds are down 

osd.0 is down since epoch 23, last address 192.168.106.220:6800/ 
11080 


果 有 硬盘 失败 或 其 它 错 误 使 ceph-osd 不 能 正常 运行 或 重启 ， 将 会 在 日 志文 件 
/var/log/ceph/ 里 输出 一 条 错误 信息 


如 果 守 护 进 程 因 心 跳 失 败 、 或 者 底层 核心 文件 系统 无 响应 而 停止 ， 查 看 dmesg 获 
取 硬 盘 RA A AK FHA TR o 


如 果 是 软件 错误 (失败 的 断言 或 其 它 意外 错误 ) ， 应 该 向 ceph-devel 邮件 列表 报 
告 o 


RARAN 


ng 不 允许 你 向 满 的 OSD 写 入 数据 ， 以 免 丢 失 数 据 。 在 运行 着 的 集群 中 ， 你 应 该 

能 收 到 集群 空间 将 满 的 警告 。 mon osd full ratio 默认 为 0.95 ， 或 达到 95% 
的 空间 使 用 率 时 它 将 阻止 客户 端 写 入 数据 。 mon osd nearfull ratio 默认 为 
0.85 ， 也 就 是 说 达到 容量 的 85% 时 它 会 产生 健康 警告 。 


满载 集群 问题 一 般 产 生 于 测试 小 型 Ceph 集群 上 如 何 处 理 OSD 失败 时 。 当 某 一 节 
点 使 用 率 较 高 时 ， 集 群 能 够 很 快 掩盖 将 满 和 占 满 率 。 如 果 你 在 测试 小 型 集群 上 的 
Ceph 如 何 应 对 OSD 失败 ， 应 该 保留 足够 的 可 用 磁盘 空间 ， 然 后 试 着 临时 降低 


mon osd full ratio 和 mon osd nearfull ratio 值 。 


ceph health 会 报告 将 满 的 ceph-osds 


ceph health 
HEALTH WARN 1 nearfull osds 
osd.2 is near full at 8596 


或 者 : 


ceph health 

HEALTH ERR 1 nearfull osds, 1 full osds 
osd.2 is near full at 85% 

osd.3 is full at 9796 


处 理 这 种 情况 的 最 好 方法 就 是 在 出 现 near full 告警 时 尽快 增加 新 的 ceph- 
osd ， 这 允许 集群 把 数据 重 分 布 到 新 OSD 里 。 


如 果 因 满载 而 导致 OSD 不 能 启动 ， 你 可 以 试 着 删除 那个 OSD 上 的 一 些 数据 。 但 
是 这 时 有 个 问题 ， 当 一 个 OSD 使 用 比例 达到 9596 时 ， 集 群 将 不 接受 任何 Ceph 
Client 端的 读 写 数据 的 请 求 。 这 时 rbd rm 删除 命令 将 不 会 得 到 响应 。 


让 集群 能 够 读 写 是 首先 要 做 的 事情 。 最 容 多 想到 的 就 是 调 高 mon osd full 
ratio 和 mon osd nearfull ratio 值 ， 但 是 对 于 生产 环境 ， 一 旦 调整 这 个 全 
局 比例 ， 可 能 会 导致 整个 集群 的 数据 都 会 动 起 来 ， 引 发 更 多 的 数据 迁移 。 因 此 另 一 
种 折 玄 方法 就 是 单独 调整 已 满 OSD 的 near full 和 full 比例 ; 也 可 以 使 用 调 低 OSD 
的 crush weight 的 方法 ， 使 已 满 OSD 上 的 数据 迁移 一 部 分 出 去 。 


# 调整 单个 osd 的 比例 
ceph tell osd.id injectargs '--mon-osd-full-ratio .98' 
ceph tell osd.id injectargs '--mon-osd-full-ratio 0.98' 


4 调整 osd 的 crush weight 4& 
ceph osd crush reweight osd.id {a-little-lower-weight-value} 


2.4 OSD 色 速 或 无 响应 


一 个 反复 出 现 的 问题 是 OSD 龟 速 或 无 响应 。 在 深入 性 能 问题 前 ， 你 应 该 先 确 保 不 
是 其 他 故障 。 例 如 ， 确 保 你 的 网 络 运 行 正常 、 且 OSD 在 运行 ， 还 要 检查 OSD 是 
否 被 恢复 流量 拖 住 了 。 


Tip i 较 新 版 本 的 Ceph 能 更 好 地 处 理 恢 复 , 可 防止 恢复 进程 耗 尽 系统 资源 而 导致 
up 且 in 的 OSD 不 可 用 或 响应 慢 。 
网 络 问题 


Ceph 是 一 个 分 布 式 存储 系统 ， 所 以 它 依 赖 于 网 络 来 互联 OSD 们 、 复 制 对 象 、 从 错 
误 中 恢复 和 检查 心跳 。 网 络 问题 会 导致 OSD 延 时 和 震荡 (反复 经 历 up and 
down， 详 情 可 参考 下 文中 的 相关 小 节 ) o 


确保 Ceph 进程 和 Ceph 依赖 的 进程 已 建立 连接 和 /或 在 监听 。 
netstat -a | grep ceph 


netstat -1 | grep ceph 
sudo netstat -p | grep ceph 


检查 网 络 统计 信息 。 


netstat -s 


驱动 器 配置 


一 个 存储 驱动 器 应 该 只 用 于 一 个 OSD 。 如 果 有 其 它 进 程 共享 驱动 器 ， 顺 序 读 写 吞 
吐 量 会 成 为 瓶颈 ， 和 包括 日 志 、 操 作 系 统 、monitor 、 其 它 OSD 和 非 Ceph 进程 。 


Ceph 在 日 志 记 录 完 成 之 后 才 会 确认 写 操作 ， 所 以 使 用 ext4 或 XFS 文件 系统 
时 高 速 的 SSD 对 降低 响应 延 时 很 有 吸引 力 。 与 之 相 比 ， btrfs 文件 系统 可 以 同 
时 读 写 日 志和 数据 分 区 。 


注意 : 给 驱动 器 分 区 并 不 能 改变 总 吞吐 量 或 顺序 读 写 限制 。 把 日 志 分 离 到 单独 的 分 
区 可 能 有 帮助 ， 但 最 好 是 另外 一 块 硬盘 的 分 区 。 
户 区 损坏 /碎片 化 硬盘 


检修 下 硬盘 是 否 有 坏 遍 区 和 碎片 。 这 会 导致 总 吞吐 量 和 急剧 下 降 。 


MON 和 OSD 共存 


Monitor 通常 是 轻 量 级 进程 ， 但 它们 会 频繁 调用 fsync() ， 这 会 妨碍 其 它 工作 负 
载 ， 特 别 是 Mon 和 OSD 共享 驱动 器 时 。 另 外 ， 如 果 你 在 OSD 主机 上 同时 运行 
Mon， 遵 遇 的 性 能 问题 可 能 和 这 些 相关 : 


e 运行 较 老 的 内 核 〈 低 于 3.0) 
e Argonaut 版 运行 在 老 的 glibc 之 上 
e 运行 的 内 核 不 支持 syncfs(2) 系统 调用 


在 这 些 情况 下 ， 同 一 主机 上 的 多 个 OSD 会 相互 拖 震 对方。 它们 经 常 导 致 爆炸 式 写 
Ao 


进程 共存 


共用 同一 套 硬 件 、 并 向 Ceph 写 入 数据 的 进程 ( 像 基 于 云 的 解决 方案 、 庶 拟 机 和 其 
他 应 用 程序 ) 会 导致 OSD 延 时 大 增 。 一 般 来 说 ， 我 们 建议 用 单独 的 主机 跑 Ceph 
、 其 它 主机 跑 其 它 进程 。 实 践 证 明 把 Ceph 和 其 他 应 用 程序 分 开 可 提高 性 能 、 并 简 
化 故障 排除 和 维护 。 


日 志 记 录 级 别 

如 果 你 为 追踪 某 问题 提高 过 日 志 级 别 ， 结 束 后 又 总 了 调 回 去 ， 这 个 OSD 将 向 硬盘 
写 入 大 量 日 志 。 如 果 你 想 始 终 保持 高 日 志 级 别 ， 可 以 考虑 给 默认 日 志 路 径 m 
/var/log/ceph/$cluster-$name.log ) 挂 载 一 个 单独 的 硬盘。 

根据 你 的 配置 ，Ceph 可 以 降低 恢复 速度 来 维持 性 能 ， 否 则 它 会 加 快 恢复 速度 而 影 
响 OSD 的 性 能 。 检 查 下 OSD 是 否 正在 恢复 。 

内 核 版 本 

检查 下 你 在 用 的 内 核 版 本 。 较 老 的 内 核 也 许 没有 反 合 能 提高 Ceph 性 能 的 代码 。 


内 核 与 SYNCFS 问题 


试 试 在 一 个 主机 上 只 运行 一 个 OSD ， 看 看 能 否 提升 性 能 。 老 内 核 未 必 支 持 有 
syncfs(2) 系统 调用 的 glibc 。 


文件 系统 问题 


当前 ， 我 们 推荐 基于 xfs 部 署 集群 。 btrfs 有 很 多 诱 人 的 功能 ， 但 文件 系统 
内 的 缺陷 可 能 会 导致 性 能 问题 。 我 们 不 推荐 使 用 ext4 ， 因 为 xattr 大 小 的 限制 破 
坏 了 对 长 对 象 名 的 支持 (RGW 需要 ) © 


内 存 不 足 


我 们 建议 为 每 OSD 进程 规划 1GB 内 存 。 你 也 许 注 意 到 了 ， 通 常情 况 下 OSD 仅 会 
使 用 一 小 部 分 (如 100 - 200MB ) 。 你 也 许 想 用 这 些 空闲 内 存 跑 一 些 其 他 应 用 ， 如 
虚拟 机 等 等 。 然 而 当 OSD 进入 恢复 状态 时 ， 其 内 存 利用 率 将 激增 。 如 果 没 有 足够 

的 可 用 内 存 ， 此 OSD 的 性 能 将 会 明显 下 降 。 


OLD REQUESTS 或 SLOW REQUESTS 


如 果 某 ems osd 守护 进程 对 一 请 求 响应 很 慢 ， 它 会 生成 日 志 消息 来 抱怨 请 求 耗 
oe AY AY Dalat Ko RUSS xe 30 秒 ， 可 以 通过 osd op complaint time 选 
项 来 配置 。 d He 况 发 生 时 ， 集群 日 志 AAT 会 收 到 这 些 消 息 9 


很 老 的 版 本 抱 奶 “old requests” : 


osd.0 192.168.106.220:6800/18813 312 : [WRN] old request osd op( 
client.5099.0:790 fatty 26485 object789 [write 0-4096] 2.5e54f64 
3) v4 received at 2012-03-06 15:42:56.054801 currently waiting f 
or sub ops 


较 新 版 本 的 Ceph 4828 "slow requests" : 


{date} {osd.num} [WRN] 1 slow requests, 1 included below; oldest 
blocked for » 30.005692 secs 

{date} {osd.num} [WRN] slow request 30.005692 seconds old, rece 

ived at {date-time}: osd op(client.4240.0:8 benchmark data ceph- 

1 39426 object7 [write 0~4194304] 0.69848840) v4 currently waiti 
ng for subops from [610] 


可 能 的 原因 有 : 


e 坏 驱 动 器 (查看 dmesg 输出 ) 

e 内 核 文 件 系统 缺陷 (查看 dmesg 输出 ) 
e 集群 过 载 (检查 系统 负载 、 iostat 等 等 ) 
e ceph-osd 守护 进程 的 bug 


可 能 的 解决 方法 : 


e 从 Ceph 主机 分 离 VM 云 解 决 方案 
e 升级 内 核 

e 升级 Ceph 

e 重启 OSD 


2.5 im 6 OSD 


我 们 建议 同时 部 署 public (前 端 ) 网 络 和 cluster (后 端 ) 网 络 ， 这 样 能 更 好 地 满足 
对 象 复制 的 网 络 性 能 需求 。 另 一 个 优点 是 你 可 以 运营 一 个 不 连接 互联 网 的 集群 ， 以 
此 避免 某 些 拒绝 服务 攻击 。 OSD 们 互联 和 检查 心跳 时 会 优选 cluster (后 端 ) 网 
络 。 
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然而 ， 如 果 cluster (后 端 网 络 失败 、 或 出 现 了 明显 的 延 时 ， 同 时 public (前 端 ) 
网 络 却 运 行 良 好 ，OSD 目前 不 能 很 好 地 处 理 这 种 情况 。 这 时 OSD 们 会 向 monitor 
报告 邻居 down 了 、 同 时 报告 自己 是 up 的 ， 我 们 把 这 种 情形 称 为 震荡 
flapping ) 。 

如 果 有 原因 导致 OSD 震荡 (反复 地 被 标记 为 ”down ， 然 后 又 up ) ， 你 可 以 强 
制 monitor 停止 这 种 震荡 状态 : 


ceph osd set noup # prevent OSDs from getting marked up 
ceph osd set nodown # prevent OSDs from getting marked down 


这 些 标记 记录 在 osdmap 数据 结构 里 : 


ceph osd dump | grep flags 
flags no-up,no-down 


可 用 下 列 命令 清除 标记 : 


ceph osd unset noup 
ceph osd unset nodown 


Ceph 还 支持 另外 两 个 标记 noin 和 noout ， 它 们 可 防止 正在 启动 的 OSD 被 
标记 为 in (可 以 分 配 数据 ) ， 或 被 误 标 记 为 out (不 管 mon osd down out 
interval 的 值 是 多 少 ) 。 


注意 : noup ^ noout 和 nodown 从 某 种 意义 上 说 是 临时 的 ， 一 旦 标记 被 清 
除了 ， 被 它们 阻塞 的 动作 短 时 间 内 就 会 发 生 。 另 一 方面 ， noin 标记 阻止 OSD 
局 动 后 加 入 集群 ， 但 其 它 守 护 进 程 都 维持 原样 。 


3. 第 见 PG 故障 处 理 


3.1 PG 无 法 达到 CLEAN KA 


创建 一 个 新 集群 后 ，PG 的 状态 一 直 处 于 active * active + remapped X 
active + degraded 状态 ， 而 无 法 达到 active + clean 状态 ， 那 很 可 能 是 
你 的 配置 有 问题 。 


你 可 能 需要 检查 下 集群 中 有 关 Pool ^ PG 和 CRUSH 的 配置 项 ， 做 以 适当 的 调 
RE o 


一 般 来 说 ， 你 的 集群 中 需要 多 于 1 个 OSD， 并 且 存 储 池 的 size 要 大 于 1 副本。 


节点 集群 


有 时 候 ， 我 们 需要 搭建 一 个 单 节点 的 Ceph 实验 环境 。 此 时 ， 在 开始 创建 monitor 
fe OSD 之前， 你 需要 把 Ceph 配置 文件 中 的 osd crush chooseleaf type 选 
项 从 默认 值 1 (表示 host 或 node ) 修改 为 0 (表示 osd ) 。 这 样 做 
是 告诉 Ceph 允许 把 数据 的 不 同 副本 分 布 到 同一 host 的 OSDs 上 。 


OSD 个 数 小 于 副本 数 


如 果 你 已 经 启动 了 2 个 OSD， 它 们 都 处 于 up 和 in 的 状态 ， 但 PG 仍 未 达到 
active + clean 状态 ， 那 可 能 是 给 osd pool default size 设置 了 一 个 大 


于 2 的 值 。 


如 果 你 想 要 在 active + degraded KA (2 BA) 操作 你 的 集群 ， 可 以 设置 
osd pool default min size 为 2， 这 样 你 就 可 以 对 处 于 active + 

Seu eon 的 对 象 写 入 数据 。 然 后 你 还 可 以 把 osd pool default size 的 值 改 
为 2， 这 样 集群 就 可 以 达到 active + clean 状态 了 。 


另外 ， 修 改 参 数 osd pool default size/min size 后 ， 只 会 对 后 面 新 建 的 
pool 起 作用 。 如 果 想 修改 已 存在 的 pool 的 size/min size ， 可 用 下 面 的 命令 


ceph osd pool set «poolname» size|min size <val> 


注意 : 你 可 以 在 运行 时 修改 参数 值 。 如 果 是 在 Ceph 配置 文件 中 进行 的 修改 ， 你 可 
能 需要 重启 集群 。 


POOL SIZE = 1 


如 果 你 设置 了 osd pool default size 的 值 为 1 > MIRRA LE 69 30) 45 
JW » OSD 依赖 于 其 他 OSD 告诉 自己 应 该 保存 哪些 对 象 。 如 果 第 一 个 OSD 持 有 对 
象 的 找 贝 ， 并 且 没 有 第 二 份 拷贝 ， 那 么 也 就 没有 第 二 个 OSD 去 告诉 第 一 个 OSD 
它 应 该 保管 那 份 拷贝 。 对 于 每 一 个 映射 到 第 一 个 OSD 上 的 PG (参考 ceph pg 
dump 的 输出 ) ， 你 可 以 强制 第 一 个 OSD 关注 它 应 该 保存 的 PGs : 


ceph pg force create pg <pgid> 


CRUSH MAP 错误 


PG 达 不 到 clean 状态 的 另 一 个 可 能 的 原因 就 是 集群 的 CRUSH Map 有 错误 ， 导 致 
PG 不 能 映射 到 正确 的 地 方 。 


3.2 卡 住 的 PGs 


有 失败 发 生 后 ，PG 会 进入 “degraded”( 降 级 ) 或 “peering”( 连 P RA RA»? 
这 种 情况 时 有 发 生 。 通 常 这 些 状 态 意味 着 正常 的 失败 恢复 正在 进行 。 然 而 ， 如 果 一 
个 PG 长 时 间 处 于 这 些 状态 中 的 某 个 ， 就 意味 着 有 更 大 的 问题 。 a monitor 在 
PG-F (stuck) 在 非 最 优 状 态 时 会 告警 。 我 们 具体 检查 : 


e inactive (不 活跃) 一 一 PG 长 时 间 不 是 active 【〈 即 它 不 能 提供 读 写 
服务 了 ) ; 

e unclean (不 干净 ) —— PG 长 时 间 不 是 clean (例如 它 未 能 从 前 面 的 失 
败 完 全 恢复 ) ; 

e stale (不 新 鲜 ) 一 一 PG 状态 没有 被 ceph-osd 更 新 ， 表 明 存 储 这 个 
PG 的 所 有 节点 可 能 都 down 了 。 


你 可 以 用 下 列 命令 显 式 地 列 出 卡 住 的 PGs : 
ceph pg dump_stuck stale 


ceph pg dump stuck inactive 
ceph pg dump stuck unclean 


FH stale 状态 的 PG i b ids ceph-osd 3 — 可 以 修复 ; bu 
inactive 状态 的 PG 通常 是 互联 问题 US ) ; 卡 在 
unclean 状态 的 PG 通常 是 a I E 
(参见 未 找到 的 对 象 ) 。 





3PG 挂 了 一 一 互联 失败 


在 某 些 情况 下 ， ceph-osd 互联 进程 会 遇 到 问题 ， 阻 值 PG 达到 活跃 、 可 用 的 状 
态 。 例 如 ， ceph health 也 许 显示 


ceph health detail 

HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs re 
covering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 i 
n osds are down 


pg 0.5 is down-*peering 
pg 1.4 is down-*peering 


osd.1 is down since epoch 69, last address 192.168.106.220:6801/ 
8651 


可 以 查询 到 PG 为 何 被 标记 为 ”down 


ceph pg 0.5 query 
{ "state": "down+peering", 


"recovery_state": [ 

{ "name": "Started\/Primary\/Peering\/GetInfo", 
"enter_time": "2012-03-06 14:40:16.169679", 
"requested_info_from": []}, 

{ "name": "Started\/Primary\/Peering", 
"enter_time": "2012-03-06 14:40:16.169659", 
"probing osds": [ 
0, 
1], 
"blocked": "peering is blocked due to down osds", 
"down osds we would probe": [ 
1], 
"peering blocked by": [ 
eosdem 
"Current lost at": 0, 
"comment": "starting or marking this osd lost 
may let us proceed"}]}, 
( "name": "Started", 
"enter time": "2012-03-06 14:40:16.169513") 


recovery state 段 告 诉 我 们 互联 过 程 因 ceph-osd 进程 挂 了 而 被 阻塞 ， 本 例 
是 osd,1 挂 了 ， 局 动 这 个 进程 应 该 就 可 以 恢复 。 


或 者 ， 如 果 osd,1 发 生 了 灾难 性 的 失败 (如 硬盘 损坏 ) ， 我 们 可 以 告诉 集群 它 丢 
&( lost ) 了 ， 让 集群 尽力 完成 副本 拷贝 。 


重要 : 集群 不 能 保证 其 它 数 据 副 本 是 一 致 且 最 新 的 ， 就 会 很 危险 | 


让 Ceph 无 论 如 何 都 继续 : 


ceph osd lost 1 


恢复 将 继续 进行 。 


3.4 未 找到 的 对 象 


某 几 种 失败 相 组 合 ， 可 能 导致 Ceph 抱怨 有 找 不 到 〈( unfound ) 的 对 象 : 


ceph health detail 
HEALTH WARN 1 pgs degraded; 78/3778 unfound (2.06596) 
pg 2.4 is active+degraded, 78 unfound 


这 意味 着 存储 集群 知道 一 些 对 象 〈 或 者 存在 对 象 的 较 新 副本 ) 存在 ， 却 没有 找到 它 
们 的 副本 。 下 例 展 示 了 这 种 情况 是 如 何 发 生 的 ， 一 个 PG 的 数据 存储 在 ceph-osd 1 
和 2 上 : 


e 1 挂 了 

e 2 独自 处 理 一 些 写 动作 

e 1 和 2 重新 互联 ，1 上面 丢失 的 对 象 加 入 队列 准备 恢复 
e. 新 对 象 还 未 拷贝 完 ，2 挂 了 


这 时 ，1 知道 这 些 对 象 存在 ， 但 是 活着 的 ceph-osd 都 没有 这 些 副本 。 这 种 情况 
下 ， 读 写 这 些 对 象 的 IO 就 会 被 阻塞 ， 集 群 只 能 指望 down 掉 的 节点 尽早 恢复 。 这 
样 处 理 是 假设 比 直接 给 用 户 返回 一 个 IO 错误 要 好 一 些 。 


首先 ， 你 应 该 确认 哪些 对 象 找 不 到 了 : 


ceph pg 2.4 list missing [starting offset, in json] 


E Monroeta road u 
“keyni uy 
"snapid": 0, 
"hash": 0, 

"max": 0}, 


"num missing": 0, 
"num unfound": 0, 


"objects": [ 
{ "oid": "object 1", 
KY Mas 
"hash": ©, 
"max": © }, 
] 
"more": 0) 


如 果 在 一 次 查询 里 列 出 的 对 象 太 多 ， more 这 个 字段 将 为 true ， 你 就 可 以 查 
询 更 多 。 


其 次 ， 你 可 以 找 出 哪些 OSD 上 探测 到 、 或 可 能 包含 数据 : 
ceph pg 2.4 query 


"recovery state": [ 

{ "name": "Started\/Primary\/Active", 
"enter_time": "2012-03-06 15:15:46.713212", 
"might_have_unfound": [ 

OSG) ak, 
"status": "osd is down"}]}, 


本 例 中 ， 集 群 知 道 osd.1 可 能 有 数据 ， 但 它 挂 了 ( down ) 。 所 有 可 能 的 状态 
A: 


e 已 经 探测 到 了 
e 在 查询 


e OSD 挂 了 


e 尚未 查询 
有 时 候 集群 要 花 一 些 时 间 来 查询 可 能 的 位 置 。 


还 有 一 种 可 能 性 ， 对 象 存 在 于 其 它 位 置 却 未 被 列 出 。 例 如 ， 集 群 里 的 一 个 ceph-osd 
43 AE. FLAK A ME , ee ; 后 来 一 系列 的 失败 导致 了 未 找到 的 对 
象 ， 它 也 不 会 觉得 早已 死亡 的 ceph-osd 上 仍 可 能 包含 这 些 对 象 。( 这 种 情况 几乎 
不 太 可 能 发 生 ) 。 


如 果 所 有 可 能 的 位 置 都 查询 过 了 但 仍 有 对 象 丢失 ， 那 就 得 放弃 丢失 的 对 象 了 。 这 仍 
可 能 是 军 见 的 失败 组 合 导 致 的 ， 集 群 在 写 操作 恢复 后 ， 未 能 得 知 写 入 是 否 已 执行 。 
以 下 命令 把 未 找到 的 ( unfound ) 对 象 标记 为 丢失 ( lost ) » 


ceph pg 2.5 mark unfound lost revert|delete 


上 述 最 后 一 个 参数 告诉 集群 应 如 何 处 理 丢失 的 对 象 。 


e delete 3 So MISC o 
e revert 选项 SONA d 会 回 滚 到 前 一 个 版 本 或 者 〈( 如 果 它 是 
新 对 象 的 话 ) MEE o RA > CT AK RAP KF ee o 


3.5 无 家 可 归 的 PG 


拥有 PG 拷贝 的 OSD 可 能 会 全 部 失败 ， 这 种 情况 下 ， 那 一 部 分 的 对 象 存 储 不 可 
用 > monitor 也 就 不 会 收 到 那些 PG 的 状态 更 新 了 。 为 检测 这 种 情况 ，monitor 会 
把 任何 主 OSD 失败 的 PG 标记 为 stale (AAs) ， 例 如 : 


ceph health 
HEALTH_WARN 24 pgs stale; 3/300 in osds are down 


可 以 找 出 哪些 PG 是 stale 状态 ， 和 存储 这 些 归 置 组 的 最 新 OSD ， 命 令 如 下 : 


ceph health detail 
HEALTH WARN 24 pgs stale; 3/300 in osds are down 


pg 2.5 is stuck stale-«active-«remapped, last acting [2,0] 


osd.10 is down since epoch 23, last address 192.168.106.220:6800 
/11080 
osd.11 is down since epoch 13, last address 192.168.106.220:6803 
/11539 
osd.12 is down since epoch 24, last address 192.168.106.220:6806 
/11861 


如 果 想 使 PG 2.5 重新 上 线 ， 例 如 ， 上 面 的 输出 告诉 我 们 它 最 后 由 osd.o 和 
osd.2 管理 ,重启 这 些 ceph-osd 将 恢复 之 (可 以 假定 还 有 其 它 的 很 多 PG 也 
会 进行 恢复 ) 。 


只 有 几 个 OSD 接收 数据 


如 果 你 的 集群 有 很 多 节点 ， 但 只 有 其 中 几 个 接收 数据 ， 检 查 下 存储 池 里 的 PO X 
量 。 因 为 PG 是 映射 到 多 个 OSD 的 ， 较 少 的 PG 将 不 能 均衡 地 分 布 于 整个 集群 。 
试 着 创建 个 新 存储 池 ， 设 置 PG 数量 是 OSD 数量 的 若干 倍 。 更 详细 的 信息 可 以 参 
考 Ceph 官方 文档 一 一 Placement Groups ° 


3.7 不 能 写 入 数据 


如 果 你 的 集群 已 启动 ， 但 一 些 OSD 没 起 来 ， 导 致 不 能 写 入 数据 ， 确 认 下 运行 的 
OSD 数量 满足 PG 要 求 的 最 低 数 。 如 果 不 能 满足 ，Ceph 就 不 会 允许 你 写 入 
数据 ， 因 为 Ceph 不 能 保证 复制 能 如 愿 进 行 。 这 个 最 低 OSD 个 数 是 由 参数 osd 
pool default min size |. o 


3.8 PG 不 一 致 


如 果 收 到 active + clean + inconsistent 这 样 的 状态 ， 很 可 能 是 由 于 在 对 

PG 做 擦洗 ( scrubbing) 时 发 生 了 错误 。 如 果 是 由 于 磁盘 错误 导致 的 不 一 致 ， 请 

sitis , picis ud ， 可 能 需要 将 这 个 磁盘 对 应 的 OSD 踢 出 集群 ， 然 后 进 
行 更 换 。 生 产 环 境 中 遇 一 致 的 问题 ， 就 是 由 于 磁盘 坏 道 导致 的 。 


当 集 群 中 出 现 PG 不 一 致 的 问题 时 ， 执 行 ceph -s 命令 会 出 现下 面 的 信息 : 


root@mon:~# ceph -s 
cluster 614e77b4-c997-490a-a3f9-e89aa0274da3 
health HEALTH ERR 
1 pgs inconsistent 
1 scrub errors 
monmap e5: 1 mons at {osd1=10.95.2.43:6789/0} 
election epoch 796, quorum © osd1 
osdmap e1079: 3 osds: 3 up, 3 in 
flags sortbitwise 
pgmap v312153: 384 pgs, 6 pools, 1148 MB data, 311 objects 
3604 MB used, 73154 MB / 76759 MB avail 
383 activet+clean 
1 active+tcleant+inconsistent 


1^ ERAT inconsistent 状态 的 问题 PG : 


root@mon:~# ceph health detail 

HEALTH ERR 1 pgs inconsistent; 1 scrub errors 

pg 9.14 is active+cleant+inconsistent, acting [1,2,0] 
1 scrub errors 


这 个 有 问题 的 PG PAE osd.1 ^ osd.2 和 osd.o E> HY osd.1 HE 
OSD ° 


2: & OSD (osd.1) 的 日 志 中 查找 不 一 致 的 具体 对 象 。 


root@osd0:~# grep -Hn 'ERR' /var/1log/ceph/ceph-osd.1.10g 
/var/log/ceph/ceph-osd.1.10g:30:2016-11-10 13:49:07.848804 7f628 
c5e6700 -1 log channel(cluster) log [ERR] : 9.14 shard 0: soid 9 
:29b4ad99:::rbd data.1349f035c101d9.0000000000000001:head missin 
g attr _ 

/var/log/ceph/ceph-osd.1.10g:31:2016-11-10 13:49:07.849803 7f628 
c5e6700 -1 log channel(cluster) log [ERR] : 9.14 scrub 0 missing 
, 1 inconsistent objects 
/var/log/ceph/ceph-osd.1.10g:32:2016-11-10 13:49:07.849824 7f628 
c5e6700 -1 log channel(cluster) log [ERR] : 9.14 scrub 1 errors 


从 日 志 中 可 以 知道 ， 是 rbd data.1349f035c101d9.0000000000000001 这 个 对 
象 的 属性 LAT > HVE scrub 的 过 程 中 产生 了 error e 


3、 执 行 ceph pg repair 命令 修复 问题 PG 。 


root@mon:~# ceph pg repair 9.14 
instructing pg 9.14 on osd.1 to repair 


4、 检 查 Ceph 集群 是 否 恢复 到 HEALTH OK 状态 。 


root@mon:~# ceph -s 
cluster 614e77b4-c997-490a-a3f9-e89aa0274da3 
health HEALTH OK 
monmap e5: 1 mons at {osd1=10.95.2.43:6789/0} 
election epoch 796, quorum © osd1 
osdmap e1079: 3 osds: 3 up, 3 in 
flags sortbitwise 
pgmap v312171: 384 pgs, 6 pools, 1148 MB data, 311 objects 
3604 MB used, 73154 MB / 76759 MB avail 
384 active-clean 


osd.1 的 日 志 里 也 提示 修复 成 功 : 


2016-11-10 14:04:31.732640 7f628c5e6700 0 log channel(cluster) 
log [INF] : 9.14 repair starts 

2016-11-10 14:04:31.827951 7f628edeb700 -1 log channel(cluster) 
log [ERR] : 9.14 shard 0: soid 9:29b4ad99:::rbd data.1349f035c10 
1d9.0000000000000001:head missing attr _ 

2016-11-10 14:04:31.828117 7f628edeb700 -1 log channel(cluster) 
log [ERR] : 9.14 repair © missing, 1 inconsistent objects 
2016-11-10 14:04:31.828273 7f628edeb700 -1 log channel(cluster) 
log [ERR] : 9.14 repair 1 errors, 1 fixed 


如 果 经 过 前 面 的 步骤，Ceph 仍 没有 达到 HEALTH OK 状态 ， 可 以 尝试 用 下 面 这 种 


1、 停 掉 不 一 致 的 object 所 属 的 osd ° 


stop ceph-osd id=xxx 


2、 刷 新 该 osd 的 日 志 。 


ceph-osd -i xx --flush-journal 


3^ 4 — 385 object & T& » 


mv /var/lib/ceph/osd/ceph- {osd-id}/current/{pg.id}_head/ rbdNNud 
ata.xxx /home 


4、 重 新 启动 该 osd » 


start ceph-osd id=xx 


o 


5、 重 新 执行 修复 命令 
ceph pg repair {pg_id} 
6» 724 Ceph 集群 是 否 恢复 到 HEALTH. OK 状态 。 


3.9 Too Many/Few PGs per OSD 


有 时 候 ， 我 们 在 ceph -s 的 输出 中 可 以 看 到 如 下 的 告警 信息 : 


root@node241:~# ceph -s 
cluster 3b37db44-f401-4409-b3bb-75585d21adfe 
health HEALTH WARN 
too many PGs per OSD (652 » max 300) 
monmap e1: 1 mons at {node241=192.168.2.41:6789/0} 
election epoch 1, quorum 0 node241 
osdmap e408: 5 osds: 5 up, 5 in 
pgmap v23049: 1088 pgs, 16 pools, 256 MB data, 2889 object 


6100 MB used, 473 GB / 479 GB avail 
1088 active+clean 


这 是 因为 集群 OSD 数量 较 少 ， 测 试 过 程 中 建立 了 多 个 存储 池 ， 每 个 存储 池 都 要 建 
xe MORD HM CODE 的 默认 值 是 每 OSD 上 最 多 有 300 ^ PGs ° EM 
试 环境 中 ， 为 了 快速 解决 这 个 问题 ， 可 以 调 大 集群 的 关于 此 选项 的 告警 阀 值 。 方 法 
如 下 : 


在 monitor 节点 的 ceph.conf 配置 文件 中 添加 : 


[global] 


mon pg warn max per osd - 1000 





然后 重启 monitor 进程 。 


或 者 直接 用 tell 命令 在 运行 时 更 改 参 数 的 值 而 不 用 重启 服务 


ceph tell mon.* injectargs '--mon pg warn max per osd 1000 





而 另 一 种 情况 ， too few PGs per OSD (16 < min 20) 这样 的 告警 信息 则 往 
往 出 现在 集群 刚刚 建立 起 来 ， 除 了 默认 的 rbd 存储 池 ， 还 没 建立 自己 的 存储 池 ， 再 
加 上 OSD 个 数 较 多 ， 就 会 NU 未 信息 。 这 通常 不 是 什么 问题 ， 也 无 需 修改 
配置 项 ， 在 建立 了 自己 的 存储 池 后 ， 这 个 告警 信息 就 会 消失 。 


4. 4 jCeph ? Az Jub 3e 


在 极端 情况 下 ， 如 数据 中 心 断 电 ， 造 成 Ceph 存储 集群 全 局 宕 机 ， 可 以 按照 本 节 所 
示 流 程 进 行 Ceph 集群 上 电 恢 复 操 作 。 


4.1 手动 上 电 执行 步骤 
1. 如 为 Ceph 集群 上 电 ，monitor server 应 最 先 上 电 ; 集群 上 电 前 确认 使 用 Ceph 
之 前 端 作 业 服 务 已 停止 。 
2. 使 用 IPMI 或 于 设备 前 手动 进行 上 电 。 
3. 确认 NTP 服务 及 系统 时 间 已 同步 ， 命 令 如 下 : 
# ps-ef | grep ntp 
# date 
# ntpq -p 
4. 登入 上 电 之 ceph server 确认 ceph service 已 正常 运行 ， 命 令 如 下 : 
# ps -ef | grep ceph 


5. 登入 集群 monitor server 查看 状态 ，OSD 全 都 up 集群 仍 为 noout flag(s) 
Set 


# Ceph -S 
# ceph osd tree 


6. € X monitor server 解除 stopping w/out rebalancing ， 命 令 如 下 : 


# ceph osd unset noout 
# ceph -w 


使 用 ceph-w V&A RA A REG ETE health 应 
为 HEALTH OK 状态 。 


4.2 恢复 后 检查 步 又 


1. 确认 设备 上 电 状 态 ， 以 |IPMI X 于 设备 前 确认 电源 为 开局 上 电 状态 。 
2. ping ceph monitor server ， 检 查 monitor server 可 以 ping 通 。 
3. 系统 时 间 和 校 时 服务 器 时 间 同 步 。 

4. ceph -s 状态 为 HEALTH_OK 

5. ceph osd tree OSD RAXA UP 


4.3 恢复 使 用 指令 及 其 说 明 


ceph -s : 确认 ceph cluster status 

ceph -w : 查看 集群 运作 输出 

ceph osd tree : 查看 ceph cluster 上 osd 排 列 及 状态 

start ceph-all : 启动 所 有 ceph service 

start ceph-osd-all : 启动 所 有 osd service 

start ceph-mon-all : 启动 所 有 mon service 

start ceph-osd id={id} : 启动 指定 osd id service 

start ceph-mon id={hostname} : 启动 指定 ceph monitor host 
ceph osd set noout : ceph stopping w/out rebalancing 


OD NO mr. s D NS 


— 


ceph osd unset noout : 解除 ceph stopping w/out rebalancing 


5. 3-^- Ceph Y &z punt X 


在 某 些 情况 下 ， 如 服务 器 硬件 故障 ， 造 成 单 台 Ceph PASMALB sb o TARR 
本 节 所 示 流 程 将 该 节点 上 的 OSD 移 除 集群 ， 从 而 达到 Ceph 集群 的 恢复 。 


5.1 单 台 Ceph 节点 宕 机 处 理 步 又 


1. 登陆 ceph monitor 节点 ， 查 询 ceph KA : 
ceph health detail 


2. 将 故障 节点 上 的 所 有 osd 设置 成 out， 该 步骤 会 触发 数据 recovery, 需要 等 待 
数据 迁移 完成 , 同时 观察 虚拟 机 是 否 正 


ceph osd out osd id 


3. 从 crushmap 将 osd 移 除 ， 该 步骤 会 触发 数据 reblance > #44 SHEILA Mm ? 
同时 观察 虚拟 机 是 否 正 常 : 
ceph osd crush remove osd name 


4. 删除 osd 的 认证 : ceph auth del osd name 


5. 删除 osd : ceph osd rm osd id 


5.2 恢复 后 检查 步骤 


.检查 ceph 集群 状态 正常 ; 

.检查 虚拟 机 状态 正常 ; 

楚 天 云 人 员 检 查 虚拟 机 业务 是 否 正 常 ; 
检查 平台 服务 正常 : nova ` cinder ` glance : 
创建 新 卷 正常 ; 

创建 虚拟 机 正常 。 
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1. PG 和 PGP 的 区 别 


本 篇 内 容 来 自 zphj1987 一 一 Ceph 中 PG 和 PGP 的 区 别 


首先 来 一 段 关 于 PG 和 PGP 区 别 的 英文 解释 : 


PG = Placement Group 

PGP = Placement Group for Placement purpose 

pg num = number of placement groups mapped to an OSD 

When pg num is increased for any pool, every PG of this pool splits into half, 
but they all remain mapped to their parent OSD. 

Until this time, Ceph does not start rebalancing. Now, when you increase the 
pgp num value for the same pool, PGs start to migrate from the parent to 
some other OSD, and cluster rebalancing starts. This is how PGP plays an 
important role. 

By Karan Singh 


以 上 是 来 自 邮 件 列表 的 Karan Singh 对 PG fe PGP 的 相关 解释 ， 他 也 是 
Learning Ceph 和 Ceph Cookbook 的 作者 ， 以 上 的 解释 没有 问题 ， 我 们 来 看 
下 具体 在 集群 里 面 如 何 作 用 。 


n ^ 
实践 


环境 准备 ， 因 为 是 测试 环境 ， 我 只 准备 了 两 台 机 器 ， 每 台 机 器 4 个 OSD， 所 以 做 
了 一 些 参数 的 设置 ， 让 数据 尽量 散 列 : 


osd crush chooseleaf type = 0 


以 上 为 修改 的 参数 ， 这 个 是 让 我 的 环境 故障 域 为 OSD 分 组 的 。 


创建 测试 需要 的 存储 池 


Oo 


我 们 初始 情况 只 创建 一 个 名 为 testpool LS 6 * PG 的 存储 池 : 


ceph osd pool create testpool 6 6 
pool 'testpool' created 


我 们 看 一 下 默认 创建 完了 后 的 PG 分 布 情 况 : 


ceph pg dump pgs|grep “1|awk '{print $1,$2,$15}' 
dumped pgs in format plain 
1.1 0 [3,6,0] 


1.0 © [7,0,6] 
1.3 © [4,1,2] 
1.2 © [7,4,1] 
1.5 0 [4,6,3] 
1.4 © [3,0,4] 


我 们 写 入 一 些 对 象 ， 因 为 我 们 关心 的 不 仅 是 PG 的 变动 ， 同 样 关心 PG 内 对 象 有 没 
有 移动 ， 所 以 需要 准备 一 些 测试 数据 ， 这 个 调用 原生 rados 接口 写 最 方便 。 


rados -p testpool bench 20 write --no-cleanup 


我 们 再 来 查询 一 次 : 


ceph pg dump pgs|grep “1|awk '{print $1,$2,$15}' 
dumped pgs in format plain 

1-1 75 3,6, 0) 

83 [7,0,6] 

144 [4,1,2] 

146 [7,4,1] 

86 [4,6,3] 

80 [3,0,4] 
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可 以 看 到 写 入 了 一 些 数据 ， 其 中 的 第 二 列 为 这 个 PG 当中 的 对 象 的 数目 ， 第 三 列 为 
PG 所 在 的 OSD e° 


增加 PG 测试 


我 们 来 扩大 PG HAA : 


ceph osd pool set testpool pg num 12 
set pool 1 pg num to 12 


ceph pg dump pgs|grep ^i|awk '{print $1,$2,$15}' 
dumped pgs in format plain 
1 37 [3,6,0] 

38 [3,6,0] 

41 [7,0,6] 

42 [7,0,6] 

48 [4,1,2] 

48 [4,1,2] 

48 [4,1,2] 

48 [7,4,1] 

49 [7,4,1] 

49 [7,4,1] 

86 [4,6,3] 

80 [3,0,4] 
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可 以 看 到 上 面 新 加 上 的 PG 的 分 布 还 是 基于 老 的 分 布 组 合 ， 并 没有 出 现 新 的 OSD 
组 合 ， 因 为 我 们 当前 的 设置 是 pgp_num 为 6, 那 么 三 个 OSD 的 组 合 的 个 数 就 是 6 
个 ， 因 为 当前 为 12 个 PG， 分 布 只 能 从 6 种 组 合 里 面 挑选 ， 所 以 会 有 重复 的 组 
A o 


根据 上 面 的 分 布 情 况 ， 可 以 确定 的 是 ， 增 加 PG 操作 会 引起 PG 内 部 对 象 分 裂 ， 分 
裂 的 份 数 是 根据 新 增 PG 组 合 重复 情况 来 确定 的 ， 比 如 上 面 的 情况 : 

e 1.1 的 对 象 分 成 了 两 份 [3,6,0] 

e 1.3 的 对 象 分 成 了 三 份 [4,1,2] 

e 1.4 的 对 象 没 有 拆 分 [3,0,4] 

结论 : 增加 PG 会 引起 PG 内 的 对 象 分 裂 ， 也 就 是 在 OSD 上 创建 了 新 的 PG A 
录 ， 然 后 进行 部 分 对 象 的 move 的 操作 。 


增加 PGP 测试 


我 们 将 原来 的 PGP 从 6 调整 到 12 : 


ceph osd pool set testpool pgp num 12 


ceph pg dump pgs|grep “1|awk '{print $1,$2,3$15]' 


dumped 
1.a 49 


ds 


[EV quen qur quant qus A eque eA RPR oe 
o Oo 人 NOON op 


可 以 看 到 PG 里 面 的 对 象 并 没有 发 生变 化 ,而 PG 所 在 的 对 应 关系 发 生 了 变化 。 


我 们 看 下 与 调整 PGP 前 后 的 对 比 : 
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48 
37 
41 
48 
48 
86 
80 
48 
49 
38 
42 


37 
38 
41 
42 
48 
48 
48 
48 
49 
49 
86 
80 


pgs in format plain 


[172,8] 
[1,6,2] 
[3,6,0] 
[7,0,6] 
[4,1,2] 
[7,4,1] 
[4,6,3] 
[3,0,4] 
[1,6,0] 
[3,6,7] 
[1,4,2] 
eZ sal 


[3,6,0] 
[3,6,0] 
[7,0,6] 
[7,0,6] 
[4,1,2] 
[4,1,2] 
[4,1,2] 
[7,4,1] 
[7,4,1] 
[7,4,1] 
[4,6,3] 
[3,0,4] 
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37 
38 
41 
42 
48 
48 
48 
48 
49 
49 
86 
80 


[3,6,0]* 
[1,4,2] 
[7,0,6]* 
[5522 37] 
[4,1,2]* 
[1,6,2] 
[1,6,0] 
[7,4,1]* 
[3,6,7] 
[1,2,6] 
[4,6,3]* 
[3,0,4]* 


可 以 看 到 其 中 最 原始 的 6 个 PG 的 分 布 并 没有 变化 (标注 了 * v) ， 变 化 的 是 后 
增加 的 PG， 也 就 是 将 重复 的 PG 分 布 进行 重新 分 布 ， 这 里 并 不 是 随机 完全 打 散 ， 
而 是 根据 需要 去 进行 重 分 布 。 


结论 : 调整 PGP 不 会 引起 PG 内 的 对 象 的 分 裂 ， 但 是 会 引起 PG 的 分 布 的 变动 。 


总 结 

e PG 是 指定 存储 池 存 储 对 象 的 目录 有 多 少 个 ，PGP 是 存储 池 PG 的 OSD 分 布 
组 合 个 数 。 

e PG 的 增加 会 引起 PG 内 的 数据 进行 分 裂 ， 分 裂 到 相同 的 OSD 上 新 生成 的 PG 
当中 。 

e PGP 的 增加 会 引起 部 分 PG 的 分 布 进行 变化 ， 但 是 不 会 引起 PG 内 对 象 的 变 
动 。 


2. Monitor 的 备份 和 恢复 


本 篇 内 容 来 自 徐 小 胖 'blog 一 一 monitor 的 增删 改 备 


Monitor 的 备份 


每 个 MON 的 数据 都 是 保存 在 数据 库 内 的 ， 这 个 数据 库 位 于 
/var/lib/ceph/mon/$cluster-$hostname/store.db ， 这 里 的 $cluster 是 
集群 的 名 字 ， $hostname 为 主机 名 ，MON 的 所 有 数据 即 目录 
/var/lib/ceph/mon/$cluster-$hostname/ ， 备 份 好 这 个 目录 之 后 ， 就 可 以 在 
任 一 主机 上 恢复 MON 了 。 


这 里 参考 了 下 这 篇 文章 里 面 的 备份 方法 ， 简 单 讲 基本 思路 就 是 ， 停 止 一 个 MON ， 
然后 将 这 个 MON 的 数据 库 压 缩 保存 到 其 他 路 径 ， 再 开局 MON。 文 中 提 到 了 之 所 
以 要 停止 MON 是 要 保证 levelDB 数据 库 的 完整 性 。 然 后 可 以 做 个 定时 任务 一 天 或 
者 一 周 备份 一 次 。 


另外 最 好 把 /etc/ceph/ 目录 也 备份 一 下 。 


这 个 备份 路 径 最 好 是 放 到 其 他 节点 上 ， 不 要 保存 到 本 地 ， 因 为 一 般 MON 节点 要 坏 


iz 


就 坏 一 台 机 器 。 


里 给 出 文中 提 到 的 备份 方法 : 


service ceph stop mon 

tar czf /var/backups/ceph-mon-backup. $(date +'%a').tar.gz /var/l 
ib/ceph/mon 

service ceph start mon 

#for safety, copy it to other nodes 

scp /var/backups/* someNode:/backup/ 


Monitor 的 恢复 


现在 有 一 个 Ceph 集群 ， 包 含 3 个 monitors : ceph-1 、ceph-2 和 ceph-3 ° 


[rootQceph-1 cluster]# ceph -s 
cluster 844daf70-cdbc-4954-b6c5-f460d25072e0 


health HEALTH OK 
monmap e2: 3 mons at {ceph-1=192.168.56.101:6789/0, ceph-2- 
192.168.56.102:6789/0, ceph-3=192.168.56.103:6789/0} 

election epoch 8, quorum 0,1,2 ceph-1,ceph-2, ceph-3 

osdmap e13: 3 osds: 3 up, 3 in 
pgmap v20: 64 pgs, 1 pools, © bytes data, © objects 
101 MB used, 6125 GB / 6125 GB avail 
64 activet+clean 


假设 发 生 了 某 种 故障 ， 导 致 这 3 6 MON 节点 全 都 无 法 启动 ， 这 时 Ceph 集群 也 将 
变 得 不 可 用 。 我 们 可 以 通过 前 面 备份 的 数据 库 文 件 来 恢复 MON。 当 某 个 集群 的 所 
有 的 MON 节点 都 挂 掉 之 后 ， 我 们 可 以 将 最 新 的 备份 的 数据 库 解 压 到 其 他 任意 一 个 
节点 上 ， 新 建 monmap * 注入， 启动 MON， 推 送 config， 重 启 OSD 就 好 了 。 


将 ceph-1 的 /var/lib/ceph/mon/ceph-ceph-1/ 目录 的 文件 拷贝 到 新 节点 
ceph-4 的 /var/lib/ceph/mon/ceph-ceph-4/ 目录 下 (或 者 从 备份 路 径 找 贝 
到 ceph-4 节点 ) ， 一 定 要 注意 目录 的 名 称 1! 这 里 ceph-1 的 IP 为 
172.23.0.101 ， ceph-4 的 IP 为 192.168.56.104 。 ceph-4 节点 为 一 个 
只 安装 了 ceph 程序 的 干净 节点 。 注 意 下 面 指令 执行 的 节点 。 


[rootQceph-1 ~]# ip a |grep 172 

inet 172.23.0.101/24 brd 172.23.0.255 scope global enpOs8 
[rootQceph-1 ~]# ping ceph-4 
PING ceph-4 (192.168.56.104) 56(84) bytes of data. 
64 bytes from ceph-4 (192.168.56.104): icmp seq-1 ttl-63 time-0. 
463 ms 


[root@ceph-4 ~]# mkdir /var/lib/ceph/mon/ceph-ceph-4 
[root@ceph-1 ~]# scp -r /var/lib/ceph/mon/ceph-ceph-1/* ceph-4: 
/var/lib/ceph/mon/ceph-ceph-4/ 


done 

100% 0 0.0KB/s 00:00 
keyring 

100% 77 0.1KB/s 00:00 
LOCK 

10096 0 0.0KB/s 00:00 
LOG 

100% 21KB 20.6KB/s 00:00 
161556.1db 


100% 2098KB 2.1MB/s 00:00 


MANIFEST - 161585 


100% 709 0. 7KB/s 00:00 
CURRENT 
100% 16 0.0KB/s 00:00 
sysvinit 
10096 0 0.0KB/s 00:00 


同时 ， 将 /etc/ceph 目录 文件 也 拷贝 到 ceph-4 节点 ， 然 后 将 ceph.conf 
中 的 mon initial members 修改 为 ceph-4 ° 


[root@ceph-1 ~]# scp /etc/ceph/* ceph-4:/etc/ceph/ 
ceph.client.admin. keyring 

100% 63 0.1KB/s 00:00 
ceph.conf 

100% 236 0.2KB/s 00:00 


[root@ceph-4 ~]# vim /etc/ceph/ceph. conf 
[root@ceph-4 ~]# cat /etc/ceph/ceph. conf 
[global] 

fsid = 844daf70-cdbc -4954-b6c5-f460d25072e0 
mon_initial_members = ceph-4 

mon_host = 192.168.56.104 


新 建 一 个 monmap， 使 用 原来 集群 的 fsid ， 并 且 将 ceph-4 加 入 到 这 个 
monmap， 然 后 将 monmap 注入 到 ceph-4 的 MON 数据 库 中 ， 最 后 启动 
ceph-4 上 的 MON 进程 。 


[root@ceph-4 ~]# monmaptool --create --fsid 844daf70-cdbc-4954-b 
6c5-f460d25072e0 --add ceph-4 192.168.56.104 /tmp/monmap 
[root@ceph-4 ~]# ceph-mon -i ceph-4 --inject-monmap /tmp/monmap 
[root@ceph-4 ~]# ceph-mon -i ceph-4 
[rootQceph-4 ~]# ceph -s 
cluster 844daf70-cdbc-4954-b6c5-f460d25072e0 
health HEALTH ERR 
64 pgs are stuck inactive for more than 300 seconds 
64 pgs degraded 
64 pgs stuck inactive 
64 pgs undersized 
monmap e6: 1 mons at {ceph-4=192.168.56.104:6789/0} 
election epoch 13, quorum 0 ceph-4 
osdmap e36: 3 osds: 1 up, 1 in 
pgmap v58: 64 pgs, 1 pools, © bytes data, © objects 
34296 kB used, 2041 GB / 2041 GB avail 
64 undersized+degraded+peered 


好 消息 是 ， ceph -s 有 了 正确 的 输出 ， 坏 消息 就 是 HEALTH ERR 了 。 不 过 不 用 
担心 ， 这 时 候 将 ceph-4 的 ceph.conf 推送 到 其 他 所 有 节点 上 ， 再 重启 OSD 
集群 就 可 以 恢复 正常 了 。 


2. Monitor 的 备份 和 恢复 
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3. 修改 Cinder/Glance 进程 的 最 大 可 用 FD 


本 篇 内 容 是 根据 生产 环境 中 遇 到 的 实际 问题 进行 的 总 结 。 


Ab wu. 

月 ^ 

在 生产 环境 中 遇 到 这 样 一 个 问题 : 

下 发 删除 卷 消息 无 法 成 功 删 除 卷 ， 过 cinder 命令 行 命令 cinder service- 
list 查询 cinder 服务 状态 ， ee cinder-volume host 
r2202002controllerQrbd-sata 服务 状态 为 DOWN ° 


| cinder-volume | r2202002controllerQrbd-sata | nova | ena 
bled | down | 


该 状态 表明 该 cinder-volume 进程 已 经 没有 正常 上 报 心 跳 ， 处 于 无 法 处 理 请 求 的 状 
X o 
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原因 分 析 


通过 现场 复 现 问题 和 查看 cinder-volume 日 志 ， 发 现在 出 问题 的 时 间 点 都 有 删除 卷 
的 操作 下 发 ， 但 是 有 的 卷 一 直 未 结束 删除 卷 流 程 ， 直 到 重启 cinder-volume 进程 时 
TRÄ ° 


2016-09-23 13:42:48.176 44907 INFO cinder.volume.manager [req-01 
82ed51-a4a7-44e4-bd3e-3d456610a135 ff01ec05ed4442799ebad096c1aa2 
921 584cbf2fed764ec9b840319eb2cd0608 - - -] volume b38ea39e-bif5 
-4af6-a7b1-40fei1d5e80ee: deleting 


2016-09-23 16:52:08.290 52145 INFO cinder.volume.manager [req-be 
3fe7fc-39fe-4bc3-9a70-d5beie7330ce - - - - -] Resuming delete on 
volume: b38ea39e-bif5-4af6-a7b1-40fei1d5e80ee 


怀疑 在 删除 RDB 卷 流程 有 挂 死 问题 ， 通 过 进一步 查看 日 志 ， 发 现 最 后 走 到 调用 
RDB Client 删除 卷 时 就 中 断 了 : 


2016-09-23 13:43:27.911 44907 DEBUG cinder.volume.drivers.rbd [r 
eq-0182ed51-a4a7-44e4-bd3e-3d456610a135 ffO01ec05ed4442799ebad096 
c1aa2921 584cb5f2fed764ec9b840319eb2cd0608 - - -] deleting rbd vo 
lume volume-b38ea39e-bif5-4af6-a7b1-40fei1d5e80 delete volume /u 
sr/local/lib/python2.7/dist-packages/cinder/volume/drivers/rbd.p 
y:666 


因为 该 问题 发 生 在 Ceph 集群 扩容 后 ， 因 此 进一步 怀疑 和 之 前 Nova 挂 卷 后 读 取 变 
慢 问 题 一 样 是 由 于 进程 打开 文件 过 多 引起 异常 ， 后 在 实验 环境 中 通过 打开 RDB 
client 日 志 ， 重 局 cinder-volume 进程 。 


[client] 

rbd cache - true 

rbd cache writethrough until flush - true 
log file = /var/1log/ceph/ceph.client.log 
debug client - 20 

debug rbd - 20 

debug librbd - 20 

debug objectcacher - 20 


然后 增加 cinder-volume 进程 删 卷 时 的 打开 文件 数 成 功 复 现 该 问题 。RDB client 日 
志 中 报 too many open files 异常 ， 后 在 生产 环境 上 通过 复 现 问题 和 打开 RDB 
Client 日 志 观 察 到 同样 的 异常 ， 因 此 可 以 确定 是 由 于 扩容 后 OSD 节点 增多 ，RDB 
client 删除 卷 时 需要 和 所 有 OSD 建立 socket 链接 ， 这 样 就 会 超过 目前 环境 中 
cinder-volume 进程 允许 打开 的 文件 数 ， 导 致 异常 发 生 ， 进 入 挂 死 状态 。 


2016-09-26 20:08:48.953810 7f099566b700 -1 -- 192.168.219.2:0/43 
062437 >> 192.168.219.130:6812/12006 pipe(Ox7fO0acdcdc090 sd--1 

© s=1 pgs-0 cs=0 l-1 c-0x7f0acdcae7e0).connect couldn't created 
socket (24) Too many open files 

2016-09-26 20:08:48.953803 7f099556a700 -1 -- 192.168.219.2:0/43 
062437 >> 192.168.219.113:6802/2740 pipe(Ox7f0acdce0330 sd--1 :0 
s=1 pgs-0 cs=0 1=1 c-Ox7fO0acdcb2210).connect couldn't created s 
ocket (24) Too many open files 

2016-09-26 20:08:48.953898 7f0995267700 -1 -- 192.168.219.2:0/43 
062437 >> 192.168.219.179:6812/31845 pipe(Ox7fOacdcfi12fO0 sd--1 

© s-1 pgs=0 cs=0 1=1 c=0x7f0acdced990).connect couldn't created 
socket (24) Too many open files 

2016-09-26 20:08:48.953913 7f099596e700 -1 -- 192.168.219.2:0/43 

062437 >> 192.168.219.169:6804/8418 pipe(Ox7fO0acdccd2fO sd=-1 :0 
s=1 pgs-0 cs=0 l-1 c-0x7f0acdcc0a90).connect couldn't created s 

ocket (24) Too many open files 

2016-09-26 20:08:48.953932 7f0995368700 -1 -- 192.168.219.2:0/43 

062437 >> 192.168.219.136:6806/23096 pipe(Ox7fOacdce8f40 sd--1 

© s=1 pgs-0 cs=0 l-1 c-0Ox7fOacdcc7cf0).connect couldn't created 
socket (24) Too many open files 


解决 方案 


由 于 问题 原因 是 cinder-volume 允许 打开 的 文件 数 没 有 随 着 Ceph 集群 的 扩容 做 相 
应 的 调整 ， 因 此 解决 方案 是 要 调整 cinder-volume 进程 的 允许 打开 文件 数 ， 目 前 调 
dX 65535 (根据 测试 ， 发 现 每 个 删 卷 请 求 要 建立 大 约 1000 多 个 链接 ， 因 此 调 
整 为 ”65535 后 可 以 支持 并 发 删除 约 60 个 RDB 卷 ， 后 续 版 本 会 考虑 基于 性 能 基 
线 ， 进 行 接口 并 发 操作 数量 的 限制 ， 防 止 无 限制 的 并 发 删 卷 导致 文件 打开 数 过 
K) 。 


1、cinder-volume 进程 被 封装 成 了 Ubuntu 上 的 upstart 任务 。 修 改 cinder-volume 
进程 启动 配置 文件 /etc/init/cinder-volume.conf ， 增 加 一 行 配 置 : 


limit nofile 65535 65535 


limit 变量 用 来 设置 任务 的 资源 限制 。 


root@Ricontrolleri:~# vi /etc/init/cinder-volume.conf 
description "Cinder Volume" 


start on (local-filesystems and net-device-up IFACE!-10) 
stop on runlevel [016] 


respawn 
limit nofile 65535 65535 


exec su -s /bin/sh -C "exec cinder-volume --config-file /etc/cin 
der/cinder.conf > /dev/null 2>&1" root 


2^ € cinder-volume 进程 ， 并 用 cat proc/pid/limits 查询 设置 是 否 生 效 。 


root@Ricontrolleri:~# service cinder-volume restart 
cinder-volume stop/waiting 
cinder-volume start/running, process 6298 


rootüR1controlleri:-£ cat /etc/6298/limits | grep open 


Max open files 65535 65535 fil 
es 


3、 检 查 cinder-volume 服务 是 否 为 UP 状态 。 


root@Ricontrolleri:~# cinder service-list 


D Fo eee i ee eS qoc Bea SS ae ee 
Pese oe p See SS Be SS Soe + 
| Binary | Host | Zone | Status 
| State | Updated at | Disabled Reason | 
deese E cec T M eo Se WR eee Spo Sagoo 
0 Te SSS SoS esa + 
| cinder -backup | OPS-controlleri | nova | enabled 
| up | 2016-09-07T20:38:30.000000 | None | 
| cinder-backup | OPS-controller2 | nova | enabled 
| up | 2016-09-07T20:38:26.000000 | None | 
| cinder-scheduler | OPS-controlleri | nova | enabled 
| up | 2016-09-07T20:38:29.000000 | None | 
| cinder-scheduler | OPS-controller2 | nova | enabled 
| up | 2016-09-07T20:38:29.000000 | None | 
| cinder-volume | OPS-controlleriQnetapp fc | nova | enabled 
| up | 2016-09-07T20:38:32.000000 | None | 
| cinder-volume | OPS-controlleriQrbd-sas | nova | enabled 
| up | 2016-09-07T20:38:33.000000 | None | 
| cinder-volume | OPS-controlleriQrbd-ssd | nova | enabled 
| up | 2016-09-07T20:38:33.000000 | None | 
| cinder-volume | OPS-controller2@rbd-sas | nova | enabled 
| up | 2016-09-07T20:38:25.000000 | None | 
| cinder-volume | OPS-controller2@rbd-ssd | nova | enabled 
| up | 2016-09-07T20:38:27.000000 | None | 
二 iege SSS peg 5 eue aes po SS cure scere 
"scere T EE Sp a oS + 


4、 重 新 进行 删除 卷 操作 ， 卷 可 以 被 正常 删除 。 


5、 因 为 Glance 后 端 也 对 接 的 是 Ceph 集群 ， 为 防止 Glance 也 出 现 该 问题 ， 建 议 
也 修改 Glance 进程 的 启动 配置 文件 /etc/init/glance-api.conf ， 增 加 
limit nofile 65535 65535 配置 行 。 


6、 重 启 glance-api 进程 。 


service glance-api restart 


7、 重 启 完 成 后 上 传 测试 镜像 ， 测 试镜 像 可 以 正常 上 传 和 删除 。 


4. #4 OSD Journal 


本 篇 中 部 分 内 容 来 自 zphj1987 





如 何 替换 Ceph 的 Journal 


Ceph 在 一 块 单独 Wp OSD 的 时 候 ， 是 默认 把 journal 和 OSD 放 在 同一 
块 磁盘 的 不 同 分 区 上 。 有 了 时候， 我 们 可 能 需要 把 OSD 的 journal 2- EJ — 4E A 
换 到 另 一 个 磁 oe 那么 应 该 怎样 替换 Ceph 的 journal 4 IX 96 ? 


有 两 种 方法 来 修改 Ceph 的 journal : 


e 创建 一 个 journal 分 区 ， 在 上 面 创 建 一 个 新 的 journal 。 
e 转移 已 经 存在 的 journal 分 区 到 新 的 分 区 上 ， 这 个 适合 整 盘 替换 。 


Ceph 的 journal 是 基于 事务 的 日 志 ， 所 以 正确 的 下 刷 journal 数据 ， 然 后 重新 
创建 journal 并 不 会 引起 数据 丢失 ， 因 为 在 下 刷 journal 的 数据 的 时 候 ，osd 是 
停止 的 ， 一 旦 数据 下 刷 后 ， 这 个 journal 是 不 会 再 有 新 的 脏 数据 进来 的 。 


JN \、 、 
第 一 种 方法 
1、 首 先 给 Ceph 集群 设置 noout 标志 。 


root@mon:~# ceph osd set noout 
set noout 


2、 假 设 我 们 现在 想 要 替换 osd.0 的 journal。 首 先 查 看 osd.0 当前 的 journal 位 置 ， 
当前 使 用 的 是 /dev/sdb2 分 区 。 


root@mon:~# ceph-disk list | grep osd.0 
/dev/sdb1 ceph data, active, cluster ceph, osd.0, journal /dev 
/ sdb2 


root@mon:~# ll /var/lib/ceph/osd/ceph-0/journal 

lrwxrwxrwx 1 root root 58 May 24 15:06 /var/lib/ceph/osd/ceph-0/ 
journal -» /dev/disk/by-partuuid/8e95b09d-ffa9-4163-b24c-b780200 
22797 

root@mon:~# ls -l /dev/disk/by-partuuid/ 

total 0 

lrwxrwxrwx 1 root root 10 Nov 8 09:21 39e9ad34-d7aa-4dec-865e-0 
8952aa8aab5 -> ../../sdc1 

lrwxrwxrwx 1 root root 10 Nov 8 09:21 8e95b09d-ffa9-4163-b24c-b 
78020022797 -> ../../sdb2 

lrwxrwxrwx 1 root root 10 Nov 8 09:21 aaecabfa-456a-4f45-8a8b-9 
de0c2642f44 -> ../../sdc2 

lrwxrwxrwx 1 root root 10 Nov 8 09:21 d30a6d4a-6da4-4a81-a9e5-4 
bc69ebeec8f -> ../../sdb1 


3、 停 止 osd.0 进程 。 


stop ceph-osd id=0 


4、 下 刷 journal 到 osd， 使 用 -i 指定 需要 替换 journal 的 osd 的 编号 。 


root@mon:~# ceph-osd -i © --flush-journal 

SG IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 Oa 00 
00 00 00 20 00 00 00 OO OO OO OO OO OO OO OO OO OO OO OO OO 00 
00 00 

SG IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 Oa 00 
00 00 00 20 00 00 OO OO OO OO OO OO OO OO OO OO OO OO OO OO 00 
00 00 

2016-11-08 13:17:58.355025 7f8351a72800 -1 flushed journal /var/ 
lib/ceph/osd/ceph-0/journal for object store /var/lib/ceph/osd/c 
eph-0 


5 » ARW 89 journal ° 


root@mon:~# ll /var/lib/ceph/osd/ceph-0/journal 

lrwxrwxrwx 1 root root 58 May 24 15:06 /var/lib/ceph/osd/ceph-0/ 
journal -» /dev/disk/by-partuuid/8e95b09d-ffa9-4163-b24c-b780200 
22797 

root@mon:~# rm -rf /var/lib/ceph/osd/ceph-0/journal 


6、 下 面 用 /dev/sdc2 分 区 重建 osd.0 的 journal 。 查 看 /dev/sdc2 的 


uuid 


root@mon:~# ls - /dev/disk/by-partuuid/ 

total 0 

lrwxrwxrwx 1 root root 10 Nov 8 09:21 39e9ad34-d7aa-4dec-865e-0 
8952aa8aab5 -> ../../sdc1 

lrwxrwxrwx 1 root root 10 Nov 8 13:17 8e95b09d-ffa9-4163-b24c-b 
78020022797 -> ../../sdb2 

lrwxrwxrwx 1 root root 10 Nov 8 09:21 aaecabfa-456a-4f45-8a8b-9 
de0c2642f44 -> ../../sdc2 

lrwxrwxrwx 1 root root 10 Nov 8 09:21 d30a6d4a-6da4-4a81-a9e5-4 
bc69ebeec8f -> ../../sdb1 


新 的 journal 的 uuid #38424  /dev/disk/by-partuuid/aaecab5fa-456a-4f45- 
8a8b-9de0c2642f44 ° 


7、 新 建 journal 的 链接 和 journal uuid 文件 : 
root@mon:~# ln -s /dev/disk/by-partuuid/aaecabfa-456a-4f45-8a8b- 
9de0c2642f44 /var/lib/ceph/osd/ceph-0/journal 


root@mon:~# echo aaecabfa-456a-4f45-8a8b-9de0c2642f44 > /var/lib 
/ceph/osd/ceph-0/journal uuid 


8^ 2% osd.0 创建 journal， 使 用 -i 指定 osd 的 编号 。 


root@mon:~# ceph-osd -i © --mkjournal 

SG IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 Oa 00 
00 00 00 20 00 OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO 00 
00 00 

2016-11-08 13:29:36.115461 7f64ec851800 -1 created new journal / 
var/lib/ceph/osd/ceph-0/journal for object store /var/lib/ceph/o 
sd/ceph-0 


9^ £4 journal ° 


root@mon:~# ceph-disk list | grep osd.0 
/dev/sdbi ceph data, active, cluster ceph, osd.0, journal /dev 
/ sdc2 


10^ È # osd.0 » 


start ceph-osd id-0 


11 ^ KM noout 的 标记 。 


ceph osd unset noout 


12、 检 查 集群 的 状态 。 


root@mon:~# ceph -s 


cluster 
health 
monmap 


osdmap 


pgmap 


614e77b4-c997-490a-a3f9-e89aa0274da3 
HEALTH OK 

eb: 1 mons at {osd1=10.95.2.43:6789/0} 
election epoch 796, quorum © osd1 
e1067: 3 osds: 3 up, 3 in 

flags sortbitwise 


v309733: 384 pgs, 6 pools, 1148 MB data, 


3597 MB used, 73162 MB / 76759 MB avail 
384 active-sclean 


root@mon:~# ceph osd tree 
ID WEIGHT TYPE NAME 
REWEIGHT PRIMARY-AFFINITY 
-4 0.05997 root default 


-1 0.01999 host mon 
0 0.01999 osd.0 
1.00000 1.00000 
-2 0.01999 host osdO 
1 0.01999 osd.1 
1.00000 1.00000 
-3 0.01999 host osdi 
2 0.01999 osd.2 
1.00000 1.00000 
AE c 、\- 、 
第 二 种 万 法 


这 个 属于 备份 和 转移 分 区 表 的 方法 。 


1、 首 先 按 方法 一 中 的 第 1~4 步 ， 设 置 noout 标志 ， 停 进 


2、 备 份 需要 替换 journal 的 分 区 表 。 


311 objects 


UP/DOWN 


up 


up 


up 


42» FJ journal » 


root@lab8106 ~# sgdisk --backup-/tmp/backup journal sdd /dev/sdd 


root@lab8106 ~# sgdisk --load-backup-/tmp/backup journal sde /de 
v/sde 
root@lab8106 ~# parted -s /dev/sde print 


新 的 journal 磁盘 现在 跟 老 的 journal 的 磁盘 的 分 区 表 一 样 的 了 。 这 意味 着 新 的 分 区 
的 UUID 和 老 的 相同 的 。 如 果 选 择 的 是 这 种 备份 还 原 的 方法 ， 那 么 journal 的 那个 

软 连接 是 不 需要 进行 修改 的 ， 因 为 两 个 磁 前 的 Wid 是 一 样 的 ， 所 以 需要 注意 将 老 

的 磁盘 拔 掉 或 者 清理 掉 分 区 ， 以 免 冲突 。 


4^ £32 journal ° 

root@lab8106 ~# ceph-osd -i © --mkjournal 
5^ È 33 

root@lab8106 ~# start ceph-osd id=0 
6^ X noout 的 标记 。 


root@lab8106 ~# ceph osd unset noout 


` 


5. 清空 OSD 的 分 区 表 后 如 何 恢 


本 篇 内 容 来 自 zphj1987 不 小 心 清空 了 Ceph 的 OSD 的 分 区 表 如 何 恢 





假设 不 小 心 对 Ceph OSD 执行 了 ceph-deploy disk zap lied > 那么 该 
OSD 对 应 磁盘 的 分 区 表 就 丢失 了 。 本 文 讲述 了 在 这 种 情况 下 如 何 进行 恢复 。 


破坏 环境 


我 们 现在 有 一 个 正常 的 集群 ， 假 设 用 的 是 默认 的 分 区 的 方式 ， 我 们 先 来 看 看 默认 的 
分 区 方式 是 怎样 的 。 


查看 默认 的 分 区 方式 。 


root@mon:~# ceph-disk list 


/dev/sdb : 

/dev/sdb1 ceph data, active, cluster ceph, osd.0, journal /dev 
/ sdb2 

/dev/sdb2 ceph journal, for /dev/sdb1 


root@mon:~# parted -s /dev/sdb print 
Model: SEAGATE ST3300657SS (scsi) 

Disk /dev/sdb: 300GB 

Sector size (logical/physical): 512B/512B 
Partition Table: gpt 


Disk Flags: 
Number Start End Size File system Name Flags 
2 1049kB  1074MB 1073MB ceph journal 


3b 1075MB 300GB 299GB xfs ceph data 


3^ RH /dev/sdb 的 分 区 表 ， 该 磁盘 对 应 的 是 osd.9 ° 


root@mon:~/ceph# ceph-deploy disk zap mon:/dev/sdb 
[ceph_deploy.conf][DEBUG ] found configuration file at: /root/.c 

ephdeploy.conf 

[ceph deploy.cli][INFO ] Invoked (1.5.34): /usr/bin/ceph-deploy 
disk zap mon:/dev/sdb 


[mon] [DEBUG ] Warning: The kernel is still using the old partiti 
on table. 

[mon] [DEBUG ] The new table will be used at the next reboot. 
[mon][DEBUG ] GPT data structures destroyed! You may now partiti 
on the disk using fdisk or 

[mon][DEBUG ] other utilities. 


即使 这 个 osd 在 被 使 用 ， 还 是 被 破坏 了 ， 这 里 假设 上 面 的 就 是 一 个 误 操 作 ， 我 们 看 
下 带 来 了 哪些 变化 : 


root@mon:~/ceph# ll /var/lib/ceph/osd/ceph-0/journal 

lrwxrwxrwx 1 root root 58 Sep 24 00:02 /var/lib/ceph/osd/ceph-0/ 
journal -» /dev/disk/by-partuuid/bd81471d-13ff-44ce-8a33-92a8df9 
e8eee 


如 果 你 用 命令 行 看 ， 就 可 以 看 到 上 面 的 链接 已 经 变 红 了 ， 分 区 没有 了 : 


root@mon:~/ceph# ceph-disk list 

/dev/sdb : 

/dev/sdb1 other, xfs, mounted on /var/lib/ceph/osd/ceph-0 
/dev/sdb2 other 


CARE MA SEU T > RA ceph 的 相关 分 区 信息 了 : 


root@mon:~/ceph# parted -s /dev/sdb print 
Model: SEAGATE ST3300657SS (scsi) 

Disk /dev/sdb: 300GB 

Sector size (logical/physical): 512B/512B 
Partition Table: gpt 

Disk Flags: 


Number Start End Size File system Name Flags 


分 区 表 完 全 没有 信息 了 ， 到 这 我 们 可 以 确定 分 区 表 完 全 没 了 ， 如 果 现 在 重启 将 会 发 
生 什 么 ?重启 以 后 这 个 磁盘 就 是 一 个 裸 盘 ， 没 有 分 区 的 裸 盘 ， 所 以 此 时 千 万 不 能 
B! 


恢复 环境 
首先 一 个 办 法 就 是 当 这 个 OSD 坏 了 ， 然 后 直接 按照 删除 节点 ， 添 加 节点 的 方法 去 


处 理 ， is 该 是 最 主流 、 最 通用 的 处 理 办 法 ， 但 是 这 个 方法 在 生产 环境 当中 引发 
的 数据 迁移 还 是 非常 大 的 。 我 们 尝试 做 恢复 ， 这 就 是 本 篇 主要 讲 的 东西 。 


1、 首 先 设置 noout 标志 。 
root@mon:~/ceph# ceph osd set noout 
2 > %21E OSD e 


root@mon:~/ceph# stop ceph-osd id=0 


现在 的 OSD 还 是 有 进程 的 ， 所 以 需要 停止 掉 再 做 处 理 。 


查看 其 他 OSD 的 分 区 信息 (这 里 要 求 磁盘 一 致 ) 。 


root@mon:~/ceph# parted -s /dev/sdc unit s print 


Model: SEAGATE ST3300657SS (scsi) 
Disk /dev/sdc: 585937500s 
Sector size (logical/physical): 512B/512B 


Partition Table: gpt 

Disk Flags: 

Number Start End Size 

Flags 

2 2048s 2097152s 2095105s 

nal 

1 2099200s 585937466s  583838267s 
记 住 上 面 的 数值 ， print 的 时 候 是 加 了 unit s 


步骤 会 用 到 的 这 些 数值 。 


4、 进 行 分 区 表 的 恢复 。 
root@mon 
5937466s 
root@mon 
97152s 


5^ BREE /dev/sdb 的 分 区 表 。 


root@mon:~/ceph# parted -s /dev/sdb print 
Model: SEAGATE ST3300657SS (scsi) 

Disk /dev/sdb: 300GB 

Sector size (logical/physical): 512B/512B 


Partition Table: gpt 

Disk Flags: 

Number Start End Size File system 
2 1049kB 1074MB 1073MB 


1 1075MB 300GB 299GB xfs 


可 以 看 到 ， 分 区 表 已 经 回来 了 。 


File system Name 
ceph jour 
xfs ceph data 


这 个 是 要 精确 的 值 的 ， 下 面 的 


:~/ceph# parted -s /dev/sdb mkpart ceph data 2099200s 58 


:~/ceph# parted -s /dev/sdb mkpart ceph journal 2048s 20 


Name Flags 
ceph journal 


ceph. data 


6^ HERD E © 


root@mon:~/ceph# umount /var/lib/ceph/osd/ceph-0 
root@mon:~/ceph# partprobe 
root@mon:~/ceph# mount /dev/sdb1 /var/lib/ceph/osd/ceph-0 


7 ^ MRE 8 journal > €3£ osd.O 的 journal ° 
root@mon:~/ceph# rm -rf /var/lib/ceph/osd/ceph-0/journal 


root@mon:~/ceph# ceph-osd -i © --osd-journal=/dev/sdb2 --mkjourn 

al 

SG IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 Oa 00 
00 00 OO 20 00 O1 cf OO OO OO OO OO OO OO OO OO OO OO OO OO 00 
00 00 

2016-09-24 00:36:06.595992 7f9dOafbc880 -1 created new journal / 
dev/sdb2 for object store /var/lib/ceph/osd/ceph-0 
root@mon:~/ceph# ln -s /dev/sdb2 /var/lib/ceph/osd/ceph-0/journa 
l 

root@mon:~/ceph# 11 /var/lib/ceph/osd/ceph-0/journal 

lrwxrwxrwx 1 root root 9 Sep 24 00:37 journal -» /dev/sdb2 


注意 上 面 的 操作 --osd-journal-/dev/sdb2 这 个 地 方 ， 此 处 写成 /dev/sdb2 
是 便于 识别 ， 这 个 地 方 在 实际 操作 中 要 写 上 /dev/sdb2 %9 uuid 的 路 径 。 


root@mon:~/ceph# 11 /dev/disk/by-partuuid/03fc6039-ad80-4b8d-86e 
c-aeeel4fb3bb6 

lrwxrwxrwx 1 root root 10 Sep 24 00:33 /dev/disk/by-partuuid/O3f 
C6039-ad80-4b8d-86ec-aeeed4fb3bb6 -> ../../sdb2 


也 就 是 这 个 链接 的 一 串 内 容 ， 这 是 为 了 防止 盘 符 串 了 的 情况 下 无 法 找到 journal 的 


问题 。 


8^» &zhb OSD » 


root@mon:~/ceph# start ceph-osd id=0 


检查 下 ， 到 这 osd.0 就 成 功 地 恢复 了 。 


6. PG + # active + remapped KA 


问题 现象 


有 时 ， 我 们 的 Ceph 集群 可 能 会 出 现 PG 长 时 间 卡 在 active + remapped 的 状 
K o 


AN 


rootQ@ceph1:~# ceph -s 
cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71 

health HEALTH_WARN 88 pgs stuck unclean 

monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, electi 
on epoch 1, quorum © cephi 

osdmap e71: 4 osds: 4 up, 3 in 

pgmap v442: 256 pgs, 4 pools, 285 MB data, 8 objects 
690 MB used, 14636 MB / 15326 MB avail 
88 active+remapped 
168 active+clean 


产生 问题 的 原因 


出 现 这 种 情况 ， 一 般 是 做 了 osd 的 reweight 操作 引起 的 ， 这 是 因为 一 般 在 做 
reweight 的 操作 的 时 候 ， 根 据 算法 ， 这 个 上 面 的 pg 是 会 尽量 分 布 在 这 个 主机 上 
的 ， 而 crush reweight 不 变 的 情况 下 ， 去 修改 osd 的 reweight 的 时 候 ， 可 
能 算法 上 会 出 现 无 法 映射 的 问题 。 


如 何 解决 


1、 直 接 做 ceph osd crush reweigh 的 调整 即 可 避免 这 个 问题 ， 这 个 straw X 
法 里 面 还 是 有 点 小 问题 的 ， 在 调整 某 个 因子 的 时 候 会 引起 整个 因子 的 变动 。 


2、 从 FIREFLY (CRUSH_TUNABLES3) 开始 CRUSH 里 面 增加 了 一 个 参数 : 


chooseleaf vary r 


是 否 递归 的 进行 chooseleaf 尝试， 如 果 非 0 ， 就 递归 的 进行 ， 这 个 基于 parent 已 
经 做 了 多 少 次 尝试 。 默 认 值 是 0， 但 是 常常 找 不 到 合适 的 mapping 。 在 计算 成 本 
和 正确 性 上 来 看 最 优 值 是 1。 对 于 已 经 有 大 量 数据 的 集群 来 说 ， 从 0 调整 为 1 将 会 
有 大 量 数值 的 迁移 ， 调 整 为 4 或 者 5 的话， 将 会 找到 一 个 更 有 效 的 映射 ， 可 以 减少 
数据 的 移动 。 


查看 当前 的 值 : 


root@cephi:~# ceph osd crush show-tunables |grep chooseleaf vary 
r 


"chooseleaf vary r": 0, 


修改 chooseleaf vary r 的 值 。 


Hammer 版 本 下 这 个 参数 默认 为 : 


tunable chooseleaf vary r 0 


修改 Crush Map 的 方法 请 参考 本 手册 第 一 部 分 9. 管理 Crushmap ° 


或 者 ， 直 接 修改 crush tunables 444 optimal 。 


ceph osd crush tunables optimal 


7. 查看 RBD 镜像 的 位 置 


有 时 ， 我 们 需要 查看 某 个 RBD 镜像 的 对 象 都 存放 在 哪些 PG 中 ， 这 些 PG 又 分 布 
在 哪些 OSD 上。 可 以 利用 下 面 的 shell 脚本 来 实现 快速 查看 RBD 镜像 的 位 置 。 


#!/bin/bash 
# USAGE: ./rbd-loc «pool» <image> 


if [ -z ${1} ] [II [ -z ${2} ]; 
then 
echo "USAGE: ./rbd-loc <pool> <image>" 
exit 1 
fi 


rbd_prefix=$(rbd -p ${1} info ${2} | grep block_name_prefix | aw 
k '{print $2}') 
for i in $(rados -p ${1} 1s | grep ${rbd_prefix}) 
do 
ceph osd map ${1} ${i} 
done 


执行 的 效果 如 下 所 示 : 


root@mon:~# rbd ls -p images 
fc5b017d-fc74-4a59-80bb-a5a76e26dd4e 


root@mon:~# ./rbd-loc.sh images fc5b017d-fc74-4a59-80bb-a5a76e26 
dd4e 

osdmap e1078 pool 'images' (9) object 'rbd data.1349f035c101d9.0 
000000000000001' -> pg 9.99b52d94 (9.14) -» up ([1,2,0], p1) act 
ing ([1,2,0], pi) 

osdmap e1078 pool 'images' (9) object 'rbd data.1349f035c101d9.0 
000000000000002' -> pg 9.40973ca2 (9.22) -> up ([0,2,1], pO) act 
ing ([0,2,1], pO) 

osdmap e1078 pool 'images' (9) object 'rbd data.1349f035c101d9.0 
000000000000003' -> pg 9.86758b2c (9.2c) -> up ([1,2,0], pi) act 
ing ([1,2,0], pi) 

osdmap e1078 pool 'images' (9) object 'rbd data.1349f035c101d9.0 
000000000000004' -> pg 9.3c8e78f6 (9.36) -> up ([0,1,2], pO) act 
ing ([0,1,2], pO) 

osdmap e1078 pool 'images' (9) object 'rbd data.1349f035c101d9.0 
000000000000000' -> pg 9.ffc971ff (9.3f) -> up ([0,2,1], pO) act 
ing ([0,2,1], pO) 


该 测试 环境 只 有 3 host? #* host.b 1 ^ OSD ^» 3 副本 设置 。 


查看 RBD 镜像 的 实际 大 小 





本 篇 内 容 来 自 zphj1987 如 何 统计 Ceph 的 RBD AXA SE 


Ceph 的 rbd 一 直 有 个 问题 就 是 无 法 清楚 的 知道 这 个 分 配 的 空间 里 面 到 底 使 用 了 多 
少 ， 使 用 rbd info 命令 查询 出 来 的 容量 是 预 分 配 的 总 容量 而 非 实际 使 用 容量 。 
在 Jewel 版 中 提供 了 一 个 新 的 接口 去 查询 ， 对 于 老 版 本 来 说 可 能 同样 有 这 个 需求 ， 
本 篇 将 详细 介绍 如 何 解 决 这 个 问题 。 


目前 已 知 的 有 三 种 查询 方法 : 


1. 使 用 rbd du 查询 (Jewel 版 才 支 持 ) 
2. 使 用 rbd diff 
3. 根据 对 和 象 统计 的 方法 进行 统计 


方法 一 : 使 用 rbd du 查询 
命令 在 Jewel 版 中 可 用 。 


root@mon:~# rbd du rbd/mysql-img 
NAME PROVISIONED USED 
test 52.8047M 0 


不 过 需要 注意 ， 执 行 此 命令 要 求 开启 rbd image 的 如 下 属性 : 
layering, exclusive-lock, object-map, fast-diff 
具体 使 用 可 参考 这 篇 文章 。 


方法 二 : 使 用 rbd diff 


root@mon:~# rbd diff rbd/mysql-img | awk '{ SUM += $2 } END { pr 
int SUM/1024/1024 " MB" }' 
52.8047 MB 


方法 三 : 根据 对 象 统 计 的 方法 进行 统计 


在 集群 非常 大 的 时 候 ， 再 按 上 面 的 方法 一 个 个 查询 ， 需 要 花 很 长 的 时 间 ， 并 且 需 要 
时 不 时 的 跟 集 群 进行 交互 。 方 法 三 是 把 统计 数据 一 次 获取 下 来 ， 然 后 进行 数据 的 统 
计 分 析 ， 从 而 获取 结果 ， 获 取 的 粒度 是 以 存储 池 为 基准 的 。 


拿 到 所 有 对 象 的 信息 : 


for obj in ‘rados -p rbd ls ;do rados -p rbd stat $obj >> obj ,tx 
t;done 


这 个 获取 的 时 间 长 短 是 根据 对 象 的 多 少 来 的 ， 如 果 担 心 出 问题 ， 可 以 换个 终端 查看 
进度 : 


ek 


tail -f obj.txt 


获取 RBD 的 镜像 列表 : 


rbd -p rbd 1s 

img2 

mysql-img 
volume-e5376906-7a95-48bb-ai1c6-bb694b4f4813.backup.base 


获取 RBD 的 镜像 的 prefix : 


root@mon:~# for a in ‘rbd -p rbd ls ;do echo $a ;rbd -p rbd info 
$a|grep prefix |awk '{print $2}' ;done 

img2 

rb.0.f4730.2ae8944a 

mysql-img 

rb.0.f4652.2ae8944a 
volume-e5376906-7a95-48bb-ai1c6-bb694b4f4813.backup.base 

rbd data.23a53c28fb938f 


获取 指定 RBD 镜 像 的 大 小 : 


root@mon:~# cat obj.txt |grep rb.0.f4652.2ae8944a |awk '{ SUM + 
= $6 ) END { print SUM/1024/1024 " MB" }' 
52.8047 MB 


将 上 面 的 汇总 ， 使 用 脚本 一 次 查询 出 指定 存储 池 中 所 有 镜像 的 大 小 : 


#!/bin/bash 
# USAGE: ./get_used.sh <poolname> 


objfile=obj.txt 
Poolname=${1} 
echo "In the pool ${Poolname}": 


for obj in ‘rados -p $Poolname 1s' 
do 

rados -p $Poolname stat $obj >> $objfile 
done 


for image in ‘rbd -p $Poolname ls~ 
do 

Imagename=$image 

Prefix= rbd -p $Poolname info $image|grep prefix |awk '{pri 
nt $2} 

Used-'cat $objfile |grep $Prefix|awk '{ SUM += $6 } END { pr 
int SUM/1024/1024 " MB" ?'^ 

echo $Imagename $Prefix 

echo Used: $Used 
done 


执行 的 效果 如 下 


root@mon:~# ./get used.sh rbd 

In the pool rbd: 

img2 rb.0.f4730.2ae8944a 

Used: 3076 MB 

mysql-img rb.0.f4652.2ae8944a 

Used: 158.414 MB 
volume-e5376906-7a95-48bb-aic6-bb694b4f4813.backup.base rbd data 
.23a53c28fb938f 

Used: 96 MB 


注意 这 里 只 统计 了 image ZONALARE WREATH clone 的 ， 存 在 容量 复 
用 的 问题 ， 需 要 自己 看 是 否 需要 统计 那 一 部 分 的 对 象 ， 方 法 同上 。 


8. 查看 RBD 镜像 的 实际 大 小 
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9. 统计 OSD 上 PG 的 数量 


我 们 可 以 通过 一 个 Python 脚本 ， 统 计 出 每 个 OSD 上 分 布 了 多 少 个 PG ， 以 此 判断 
集群 的 数据 分 布 是 否 均 衡 。 


#!/usr/bin/env python 
import sys 
import os 
import json 
cmd = ''' 
ceph pg dump | awk ' /^pg stat/ { col=1; while($col!="up") {col+ 
+}; col++ } /^[0-9a-f]-**.[0-9a-f]*/ {print $1,$col}' 
body = os.popen(cmd).read() 
SUM = {} 
for line in body.split('\n'): 
if not line.strip(): 
continue 
SUM[line.split()[0]] = json.loads(line.split()[1]) 
pool = set() 
for key in SUM: 
pool.add(key.split('.')[0]) 
mapping = {} 
for number in pool: 
for k,v in SUM.items(): 
if k.split('.')[0] == number: 
if number in mapping: 
mapping[number] += v 
else: 
mapping[number] = v 
MSG = """%(pool)-6s: %(pools)s | SUM 
%(line)s 
%(dy)s 
%(line)s 
%(sun)-6s: %(end)s |""" 
pools = " ".join(['%(a)-6s' % ("a": x} for x in sorted(list(mapp 


ing))]) 
line = len(pools) + 20 
MA = (3 
OSD - [] 
for p in mapping: 
osd - sorted(list(set(mapping[p]))) 


OSD += osd 
count = sum([mapping[p].count(x) for x in osd]) 
osds = {} 


for x in osd: 
osds[x] = mapping[p].count(x) 
MA[p] = {"osd": osds, "count": count} 
MA = sorted(MA.items(), key-lambda x:x[0]) 
OSD = sorted(list(set(OSD) )) 
DY Saou" 
for osd in OSD: 
count = sum([x[1]["osd"].get(osd,0) for x in MA]) 
w = ["%(x)-6s" % ("x": x[1]["osd"].get(osd,0)} for x in MA] 
#print w 
w.append("| %(x)-6s" % {"x": count}) 
DY += 'osd.%(osd)-3s %(osds)s\n' % ("osd": osd, "osds": " ". 


join(w) } 
SUM = " '";joan(["9(x)-6s" % ("x": x[1]["count"]} for x in MAT) 
msg = {"pool": "pool", "pools": pools, "line": "-" * line, "dy": 


DY, "end": SUM, "sun": "SUM"} 
print MSG % msg 


执行 效果 如 下 : 


rootQOPS-cephi1:-4 ./cal pg per osd.py 
dumped all in format plain 


pool : 0 1 2 3 4 5 7 | SUM 
osd.0 2 9 11 10 5 6 1 | 44 
osd.1 1 7 8 10 8 9 3 | 46 


osd.2 2 11 7 6 6 8 4 | 44 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


osd. 


10 


11 


12 


13 


14 


15 


16 


17 


18 


19 


20 


21 


22 


10 


11 


12 


10 


56 


36 


41 


42 


36 


56 


40 


42 


44 


50 


10 


12 


13 


11 


39 


12 


10 


47 


48 


42 


52 


47 


47 


45 


40 


41 


42 


13 


10 


12 


45 


12 


49 


45 


37 


41 


51 


44 


45 


56 


49 


38 


11 


10 


10 


30 


11 


38 


55 


35 


55 


39 


41 


51 


46 


48 


49 


10 


43 


13 


43 


42 


49 


36 


43 


46 


46 


44 


52 


38 


10 


15 


15 


12 


46 


16 


10 


15 


12 


15 


12 


11 


12 


12 


40 


62 


47 


252 


242 


223 


244 


241 


252 


244 


243 


246 


233 


46 


48 


57 


51 


54 


48 


219 


osd.23 6 44 38 44 38 41 6 | 217 


osd.24 7 37 50 49 49 36 8 | 236 
osd.25 10 28 38 44 40 32 11 | 203 
osd.26 1 44 33 47 47 37 13 | 222 
osd.27 3 47 38 42 44 55 14 | 243 
osd.28 4 47 47 34 33 48 11 | 224 
osd.29 3 40 32 34 40 51 10 | 210 
osd.30 8 39 46 47 55 35 10 | 240 
osd.31 5 48 48 45 41 36 11 | 234 
osd.32 5 46 48 53 42 48 7 | 249 


SUM : 128 1024 1024 1024 1024 1024 256 | 


10. 查看 使 用 RBD 镜像 的 客户 端 


有 时 候 删 除 rbd image 会 提示 当前 rbd image 正在 使 用 中 ， 无 法 删除 : 


rbd rm foo 

2016-11-09 20:16:14.018332 7f81877a07cO -1 librbd: image has wat 
chers - not removing 

Removing image: 0% complete...failed. 

rbd: error: image still has watchers 

This means the image is still open or the client using it crashe 
d. Try again after closing/unmapping it or waiting 30s for the c 
rashed client to timeout. 


所 以 希望 能 查看 到 底 是 谁 在 使 用 rbd image » 


对 于 rbd image 的 使 用 ， 目 前 主要 有 两 种 形式 : 内 核 模 块 map 后 再 mount. ; 通过 
libvirt 等 供给 虚拟 机 使 用 。 都 是 利用 rados listwatchers 去 查看 ， 只 是 两 种 形 
式 下 需要 读 取 的 文件 不 一 样 。 


内 核 模 块 map 


查看 方法 如 下 : 


4 查看 rbd pool 中 的 image 
root@cephi:~# rbd ls 

foo 

ltest 

test 


4 查看 foo 的 使 用 者 
root@cephi:~# rados -p rbd listwatchers foo.rbd 
watcher=10.202.0.82:0/1760414582 client.1332795 cookie=1 


# 去 对 应 主机 上 检查 
root@ceph2:~#rbd showmapped |grep foo 
O rbd foo - / dev/rbdO 


虚拟 机 通过 libvirt 使 用 rbd image 
查看 方法 如 下 : 


# 查看 该 虚拟 机 卷 的 信息 
rootQ@ceph1:~# rbd info volumes/volume-ee0c4077-a607-4bc9-a8cf-e8 
93837361f3 
rbd image 'volume-ee0c4077-a607-4bc9-a8cf-e893837361f3': 
size 1024 MB in 256 objects 
order 22 (4096 kB objects) 
block name prefix: rbd data.13c3277850f538 
format: 2 
features: layering, striping 
flags: 
parent: images/3601459f-060b-460f-b73b-db74237d922eQsnap 
overlap: 40162 kB 
stripe unit: 4096 kB 
stripe count: 1 


4 查看 该 image 的 使 用 者 

root@cephi:~# rados -p volumes listwatchers rbd header.13c327785 
0f538 

watcher=10.202.0.21:0/1043073 client.1298745 cookie=140256077850 
496 


我 们 登录 控制 节点 ， 查 看 对 应 的 cinder &: 


root@controller:~# cinder list | grep ee0c4077-a607-4bc9-a8cf-e8 

93837361f3 

| ee0c4077-a607-4bc9-a8cf-e893837361f3 | in-use | | a | 
- | true | 96ee1aad-af27-4c9d-968f-291dbb2766a1 | 


该 卷 挂 载 在 ID A  96eeiaad-af27-4c9d-968f-291dbb2766a1 的 虚拟 机 上 。 通 过 
nova show 命令 验证 该 虚拟 机 是 否 在 物理 机 10.202.0.21 ( computer21 ) 上 : 


root@controller:~# nova show 96ee1aad-af27 -4c9d-968f -291dbb2766a 


dete SSS See SOR eases oie Sareea tase 1 ee 
aes te Ds ROE RS ee de rcr ud tesis ds Ed Re a Se a eee ae CUBE DE das + 
| Property | Value 
了 eese see eA eU 45586555 
lH A A cie e eR es ee M A P UA UA Ad E Anat Bean SoMa eM E cO e E Dene mah emus Rene ma AES CUM + 
| OS-DCF:diskConfig | AUTO 
| 
| OS-EXT-AZ:availability zone | az ip 
| 
| OS-EXT-SRV-ATTR: host | computer21 
| 
| OS-EXT-SRV-ATTR: hostname | byp-volume 
| 
| OS-EXT-SRV-ATTR:hypervisor hostname | computer21 
| 
| OS-EXT-SRV-ATTR:instance name | instance-00000989 


| 
| OS-EXT-SRV-ATTR:kernel id | 


| OS-EXT-SRV-ATTR: launch index | 9 


| OS-EXT-SRV-ATTR:ramdisk id | 


| OS-EXT-SRV-ATTR:reservation id | r-hwiyxi5c 


| OS-EXT-SRV-ATTR:root device name | /dev/vda 


| OS-EXT-SRV- 


| OS-EXT-STS: 


| OS-EXT-STS: 


| OS-EXT-STS 


| OS-SRV-USG: 


000 


| OS-SRV-USG: 


| accessIPv4 


| accessIPv6 


| blue-net ne 


| config driv 


| created 


| description 


| flavor 


| hostid 


4563a0cbac461f86523c5c81f5d18069e 


| host status 


| id 
-291dbb2766a1 
| image 

lume - no ima 
| key name 


| locked 


| metadata 


ATTR:user data 


power state 


task state 


:vm state 


launched at 


terminated at 


twork 


e 


ge supplied 


active 


| 
2016-11-09T08:19:41.000 


192.168.50.27 


| 
2016 -11-09T07:53:59Z 


| 
byp-volume 


mi.small (2) 


| 
5104ee1a0538048d6ef80b1 


| 
UP 


| 
96ee1aad-af27-A4c9d-968f 


| 
Attempt to boot from vo 


Octavia ssh key 


False 


{} 


| name | byp-volume 


| os-extended-volumes:volumes attached | [{"id": "ee0c4077-a607- 
4bc9-a8cf-e893837361f3", "delete on termination": truej] | 
| progress | 0 

| 
| security groups | default 

| 
| status | ACTIVE 

| 
| tenant id | f21a9c86d7114bf99c711f4 
874d80474 | 
| updated | 2016-11-09T08:19:41Z 

| 
| user id | 142d8663efce464c89811c6 
3e45bd82e | 
| zq-test network | 192.168.6.6 

| 
了 于 


